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ABSTRACT 

This  thesis  concerns  the  analysis,  design,  and  partial  implementation  of  a 
software  package  to  automate  the  present  manual  system  of  conventional  ammunition 
management  onboard  most  ships  of  the  U.S.  Navy.  Structured  analysis  and  design 
techniques  are  utilized  in  the  developement  and  approximately  one  quarter  of  the 
application  programs  have  been  implemented. 

The  system  is  designed  for  stand  alone  operation  on  an  IBM  compatible 
microcomputer  using  the  relational  database  package  dBase  III  Plus  by  Ashton-Tate. 

Follcw-on  work  would  consist  of  completing  the  application  programs,  select  a 
pilot  vessel  and  install  the  system,  collect  user  comments,  and  modify  the  system  as 
necessarv. 
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I.  INTRODUCTION 

A  continuous  chain  of  ammunition,  fuel  and  equipment  is  the  life  blood  of  a 
military  organization  in  wartime.  The  incredible  speed  and  attrition  of  modern  warfare 
requires  the  proper  placement,  both  in  type  and  quantity,  of  ammunition  in  peacetime 
to  meet  the  expected  demands  of  a  major  conflict. 

The  world-wide  commitments  of  the  United  States  and  its  allies  dictate  a  logistics 
system  which  is  exceedingly  complex.  The  global  stockpiling  of  conventional 
ammunition  is  perhaps  one  of  the  more  complex  problems  military  planners  must 
soive.  Not  only  does  this  stock  require  very  accurate  accounting  and  physical  security, 
but  it  is  perishable  in  nature  and  its  serviceability  must  be  continually  reviewed.  During 
the  Vietnam  war.  Navy  ammunition  procurement  reached  a  high  of  S98S  million 
[Ref.  1:  p.  24]  with  world-wide  inventories  valued  at  approximately  S7  billion  dollars.  It 
was  during  this  period  that  the  Chief  of  Naval  Operations  directed  the  establishment  of 
a  single  point  of  reference  within  the  Navy  for  conventional  ammunition  management. 
The  Chief  of  Naval  Material  was  given  the  responsibility  for  the  establishment  of  a 
Conventional  Ammunition  Integrated  Management  System  (CALMS).  One  of  the 
prime  operational  purposes  of  CALMS  [Ref.  2],  was  to  improve  the  quality  of 
ammunition  stock  status  reaching  higher  echelon  logistics  planners.  CALMS  is  the 
point  of  reference  regardless  of  inventory  management  or  ownership  responsibilities. 
Perhaps  most  important  to  the  end-user,  it  was  the  stated  policy  of  CALMS  to 
minimize  the  reporting  burden  of  field  activities.  For  example,  ships  were  to  report 
expenditure  and  inventory  information  to  CAIMS  only,  and  CAIMS  would  further 
distribute  the  information  as  necessary  to  other  interested  parties. 

CAIMS  was  established  and  is  directed  by  the  Navy  Ship's  Parts  Control  Center 
iSPCCi  at  Mechanicsburg,  PA.  Program  guidance  is  promulgated  by  SPCC  [Ref.  3] 
and  is  further  defined  with  specific  implementing  and  reporting  instructions  in  Fleet 
Commander  instructions  [Refs.  4.5]. 

The  program  has  been  successful  in  many  respects,  however  several  audits  in  the 
early  1980's  conducted  by  the  US  General  Accounting  Office  (GAO)  and  the  Naval 
Audit  Service  found  significant  discrepancies  between  on-site  local  records  and  CAIMS 
data.  This  brougnt  into  question  the  Navy's  ability  to  maintain  accountability  for  it's 


S7  billion  plus  ammunition  inventor}'  [Refs.  6,7,8].  Future  negotiations  for  ammunition 
appropriations  depend  on  the  mutual  assurance  of  a  credible  inventor}'  management 
system.  The  timely  and  accurate  reporting  from  the  hundreds  of  field  activities  and 
ships  is  critical  therefore  to  the  success  of  the  overall  system. 

Although  CAIMS  as  a  whole  has  become  highly  automated,  linking  SPCC,  the 
major  stock  points,  and  other  organizations  in  the  logistics  hierarchy,  the  majority  of 
end-users  enjoy  no  such  capabilities. 

A.       PURPOSE 

This  thesis  will  suggest  a  method  to  automate  the  present  manual  record  keeping, 
report  writing,  and  inventory  control  procedures  in  use  on  nearly  all  US  Navy  surface 
and  submerged  combatants.  It  is  felt  that  the  present  procedures  contribute  to  the  high 
error  rate  in  transaction  reporting  and  inventory  management.  For  activities  that  can 
dedicate  an  individual  or  individuals  to  the  sole  task  of  properly  keeping  the  necessary 
records  and  generating  the  required  reports,  automation  may  seem  unnecessary. 
However,  the  proposed  system  will  increase  the  accessibility  of  ammunition  and 
inventory  information,  greatly  reduce  storage  requirements,  and  reduce  the  time 
required  to  manage  the  system.  Therefore  any  activity  should  benefit  and  avail  itself  of 
a  properly  designed  system  that  satisfies  the  functional  requirements.  The  fact  is,  most 
ships  do  not  have  the  luxury  of  assigning  an  individual  to  study  this  system  and 
become  an  expert.  The  list  of  important  administrative  and  record  keeping  tasks  on  a 
typical  naval  vessel  often  exceeds  the  crew  size  by  a  large  margin.  This  thesis  then  will 
also  attempt  to  lessen  the  administrative  burden  on  weapons  department,  and  in  some 
cases  supply  department,  personnel  who  are  charged  with  the  responsibility  of 
conventional  ammunition  management. 

This  automated  software  solution  shall  be  called  the  Shipboard  Ammunition 
Management  System  (SAMS)  and  shall  encompass  all  areas  of  routine  ammunition 
management.  The  scope  of  this  thesis  will  carry  the  project  through  the  analysis, 
design,  and  partial  implementation  of  critical  areas  of  the  application  programs. 
Complete  implementation  and  additional  research  shall  be  discussed  in  Chapters  5  and 
6.  It  was  particularly  desired  to  start  the  implementation  in  this  thesis  because  many 
good  ideas  never  seem  to  bridge  the  void  between  paper  and  code  on  a  project  as 
restricted  in  time  as  a  thesis  necessanlv  is. 
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B.       MOTIVATION 

The  impetus  for  this  project  came  from  the-  observation  of  the  need  by  this 
author  during  several  tours  of  duty  on  submarines  of  the  Atlantic  and  Pacific  Fleets. 
Although  the  quantities  of  conventional  ammunition  carried  onboard  submarines  is 
considerably  less,  in  quantity  and  variety,  than  most  surface  combatants,  it  was  still 
obvious  that  an  automated  system  could  greatly  improve  the  efficiency  of  the  system. 
As  discussed  earlier,  the  many  necessary  administrative  functions  onboard  a  vessel 
generally  Co  not  decrease  in  proportion  to  crew  size,  so  many  smaller  vessels  suffer 
more  in  this  respect.  Additionally,  enlisted  rate  training  is  particularly  brief  in  the  areas 
of  conventional  ammunition  management  [Ref.  9:  p.  12-1].  Officer  training  is 
essentially  nil  in  this  area  also.  Therefore,  the  accurate  and  timely  reports  that  CAIMS 
requires  to  maintain  an  accounting  of  Navy  assets  is  being  furnished  by  people  with 
little  time  or  training  to  become  proficient  in  yet  another  administrative  task.  Now 
obviously,  shipboard  personnel  are  using  the  available  publications  and  are  supplying 
reasonably  accurate  information  to  the  CAIMS  system  otherwise  there  would  be  much 
higher  level  attention  to  this  problem.  This  author  contends  that  SAMS  will  make 
more  time  available  for  important  operational  and  weapons  employment  training. 

Automating  a  previously  manual  task  requires  consideration  of  the  operator's 
ability  to  operate  the  system  by  back  up  methods  when  necessary.  The  automated 
system  must  not  be  so  abstract  and  "automatic"  that  the  manual  skills  and  knowledge 
of  the  underlying  procedures  are  forgotten.  Therefore,  any  system  of  this  type  must  be 
instructive  as  well  as  functional.  Such  a  system  has  elements  of  an  expert  system.  It  is 
developed  by  previous  users  who  have  acquired  the  proper  education  and  training  to 
implement  a  software  solution,  and  pass  on  that  expertise  to  the  current  users  while 
satisfying  the  functional  requirements.  This  type  of  user  interface  could  become 
extremely  tedious  if  the  system  is  used  frequently  and  so  a  balance  must  be  struck 
between  efficieny  of  data  entry  and  the  degree  of  explanatory  information. 

Lastly,  it  is  unfortunate  that  the  very  personnel  who  require  relief  from 
administrative  burdens  often  have  neither  the  time  or  training  to  affect  the  change  to 
automation.  Thus  it  is  particularly  appropriate  that  shore  commands  and  the  Naval 
Postgraduate  School  solve  these  types  of  problems  in  addition  to  more  basic  research. 
The  making  available  of  time  to  train  in  relevant  warfare  topics  is  at  the  heart  of 
current  drives  to  reduce  administrative  and  paperwork  tasks  within  the  Navy. 
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C.       CHAPTER  OUTLINE 

Chapter  1  has  discussed  the  importance  of  accountability  and  inventor.' 
management  of  conventional  ammunition  within  the  Navy.  A  broad  discussion  of  the 
logistics  hierarchy  has  highlighted  the  necessity  of  accurate  and  timely  information 
flowing  up  from  the  hundreds  of  field  activities  and  ships.  The  purpose  oi~  this  thesis 
was  stated  to  be  a  software  application  package  to  automate  the  tedious  and  complex 
manual  record  keeping  required  at  the  fleet  end-user  level. 

Chapter  2  will  describe  the  present  manual  system  of  ammunition  management  in 
detail  and  point  out  the  problems  inherent  in  these  procedures.  The  references  for  the 
manual  system  will  be  examined  to  illustrate  the  difficult  task  of  interpreting  this  large 
volume  of  often  overlapping  documentation.  Examples  of  data  redundancy  will  be 
examined  to  help  understand  why  internal  record  keeping  is  more  complex  than  it 
should  be.  Finally,  the  lack  of  standardized  procedures  for  the  end-user  management  of 
ammunition  will  be  discussed  in  light  of  the  improvements  available  from  a 
standardized  software  application. 

Chapter  3  describes  the  methodology  for  the  developement  of  a  software  solution 
to  the  problem.  The  analysis  phase  is  considered  in  detail  and  system  data  elements  are 
identified.  A  tailored  Data  Element  Dictionary  (DED)  is  developed  and  Data  Flow 
Diagrams  (DFDs)  illustrate  the  proposed  system  as  levels  of  process  descriptions. 
Finally,  the  advantages  of  a  database  solution  and  normalization  theory  are  discussed. 

Chapter  4  provides  the  technical  details  of  the  relations,  fields,  indexes  and  keys 
with  respect  to  relational  database  design  and  normalization.  The  transition  from 
logical  to  physical  process  descriptions  takes  place  with  the  developement  of  structure 
charts  for  the  system.  The  qualities  of  good  modular  design  are  discussed  and  the 
effects  programming  in  dBase  III  Plus  has  on  these  qualities. 

Chapter  5  discusses  the  application  code  that  has  been  implemented  for  this 
thesis  and  the  reasons  for  selecting  these  programs.  Coding  design  decisions  and  style 
are  discussed  in  light  of  the  potential  end-users  and  frequency  of  use.  System 
expandability  and  flexibility  are  highlighted. 

Chapter  6  contains  recommendations  for  future  research  and  comments  and 
conclusions. 

The  Appendices  will  consist  of: 

a.  Data  Flow  Diagrams 

b.  Data  Element  Dictionary 

c.  Program  Directory 

12 


d.  Structure  Charts 

e.  Program  Code  Listings 

f.  Programs  Diskette 
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II.  PRESENT  MANUAL  AMMUNITION  MANAGEMENT  /  PROBLEMS 

Naval  units  are  required  to  maintain  records  and  submit  reports  which  provide 
accountability  of  conventional  ammunition  and  allow  reconciliation  of  Navy 
ammunition  assets  world-wide. 

As  a  preface  to  a  discussion  of  the  inventory  control  procedures,  it  is  worthwhile 
to  review  the  item  control  methods  used  within  the  Navy.  The  military  services 
participate  in  the  Federal  Cataloging  System  [Ref.  10:  sec.  2032],  Most  NATO 
countries  also  participate  in  the  L'nitcd  States  Item  Identification  Code,  for  military 
standardization  purposes,  under  NATO  Standardization  Agreement  3151  [Ref.  10:  sec. 
2035].  All  conventional  ammunition  items  at  the  end-user  level  should  conform  to  the 
Federal  Cataloging  System.  These  items  are  assigned  a  National  Stock  Number  (NSN) 
by  the  Defense  Logistics  Services  Center  (DLSC)  at  Battle  Creek.  Michigan. 

An  NSN  is  a  13-digit  stock  number,  see  Figure  2.1  ,  and  is  composed  of  a  4-digit 
Federal  Supply  Classification  (FSC)  followed  by  a  9-  digit  National  Item  Identification 
Number  (NUN).  An  FSC  describes  a  "family"  of  items  of  supply  sharing  such  common 
characteristics  as  nomenclature,  end  application,  or  physical  construction.  For  example, 
the  FSC  1345  is  the  bomb  "familv"  of  conventional  ammunition. 


1345 
1     1 

-   00 

1 

-   1234567 

FSC 
1 

NIIN 

1 

NSN 

Figure  2.1     National  Stock  Number  breakdown. 

The  first  two  digits  of  the  NUN  are  the  National  Codification  Bureau  (NCB)  code,  and 
are  essentially  a  country  code  (and  in  some  publications  referred  to  as  that),  within  the 
NATO  framework.  The  United  States  is  assigned  the  NCB  "00"  and  since  it  is  always 
part  of  the  NIIN  we  will  no  longer  distinguish  it  from  the  NIIN.  A  NIIN  uniquely 
identifies  an  item  in  the  Federal  Cataloging  System. 
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Item  identification  unfortuneately  gets  a  bit  more  complicated.  The  Department 
cf  Defense  (DoD)  has  established  a  Department  of  Defense  Ammunition  Code 
(DODAO.  which  is  an  8-digit  code  consisting  of  a  4-digit  FSC  (same  as  previously 
mentioned),  and  a  4-digit  DoD  Identification  Code  (DODIC).    See  Figure  2.2  . 


1345 (    -      A011 

rs^"'       'dctjt 


DODAC 


Figure  2.2     Department  of  Defense  Ammunition  Code. 

To  proceed  further,  the  Navy  Ship's  Parts  Control  Center  (SPCC)  has  assigned  a 
4-digit  Navy  Ammunition  Logistics  Code  (NALC)  to  certain  end  round  missiles  and 
torpedoes.  The  NALC  is  similar  to  the  DODIC  except  that  it  is  assigned  by  SPCC 
rather  than  DLSC.  See  [Ref.  11].  NALC's  are  listed  in  the  Stock  List  of  Navy 
Ammunition.  TWO10-AA-ORD-010  [Ref.  12],  along  with  the  DODIC  if  a  NALC  has 
not  been  assigned. 

A  particular  item  will  have  a  unique  FSC,  a  unique  NUN,  but  may  have  either  a 
NALC  or  a  DODIC.  Figure  2.3  may  help  illustrate  this  point. 


FSC      +      NUN      =      NSN 

FSC   +   DODIC/NALC   =   DODAC 


Figure  2.3     Identification  Number  Composition. 

Until  recently,  Navy  ammunition  items  were  tracked  by  NALC  vice  NUN,  and  it 
is  obvious  that  since  a  NALC  does  not  uniquely  describe  an  item  but  a  group  of  very 
similar  items,  accurate  stock  knowledge  was  not  possible  for  the  end-user  accounts. 
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Items  of  the  same  NALC  DODIC  are  normally  functionally  compatible,  but  may  have 
small  differences.  For  example,  NALC  A015  is  for  12  gauge  shotgun  shells,  00  buck, 
but  one  NUN  is  for  a  shell  with  paper  cases  and  one  has  plastic  cases.  Apparently 
recognizing  the  lack  of  accuracy  that  results  from  NALC  reporting,  SPCC  is  now 
emphasizing  NUN  reporting  on  all  documents.  An  automated  system  should  enforce 
this  more  logical  approach,  while  still  maintaining  the  NALC  identity  because  it  is  still 
widely  used  for  referring  to  an  ammunition  type.  The  Stock  List  of  Navy  Ammunition, 
mentioned  earlier,  contains  cross  referencing  for  this  purpose,  as  well  as  being  the 
prime  source  of  generic  information  about  conventional  ammunition  within  the  Navy. 
Coast  Guard,  and  Marine  Corps.  It  is  updated  regularly  on  microfiche  and  held  by  all 
activities  with  Navy  ammunition. 

To  conclude  this  discussion  of  item  identification,  two  additional  terms  are 
important.  Ammunition  Lot  Numbers  (ALN's)  or  just  Lot  Numbers,  are  assigned  by 
loading,  manufacturing,  or  assembly  activities  to  identify  homogeneous  material  that 
should  function  in  a  "near  identical"  manner.  The  lot  number  is  also  important  to  allow 
tracking,  to  maintain  performance  and  surveillance  records,  and  allow  suspension  or 
recall  if  necessary.  New  items  are  assigned  ALN's  in  accordance  with  MILSTD-1 168A, 
however  much  older  ammunition  is  still  in  the  inventory  with  less  uniform  lot  number 
formats.  Finally,  serial  numbers  are  assigned  to  high  value  or  special  interest  items  to 
allow  individualized  tracking. 

A.       INVENTORY  RECORDS 

Three  types  of  record  cards  are  used  onboard  ships  for  inventory  control. 

1 .  Master  Stock  Record  Card 

The  Ammunition  Master  Stock  Record  Card,  NAVSL'P  Form  1296,  Figure 
2.4  .  is  kept  for  each  NALC'DODIC  carried  onboard.  The  card  provides  a  history  of 
the  transactions  that  have  occured  effecting  the  quantity  or  status  of  that  item. 
Changes  to  the  quantities  in  the  inventory  can  take  place  by  receipts,  issues,  or 
expenditures.  Expenditures  can  occur  due  to  combat  operations,  training,  test  and 
evaluation,  exercises,  and  other  reasons.  Each  form  of  transaction  has  a  one  character 
code,  the  Transaction  Code,  that  describes  it.  These  codes  are  explained  and  listed  in 
the  SPCC  CAIMS  manual  [Ref.  3:  p.  8-5-35]. 

If  material  is  received  or  issued  it  will  have  a  corresponing  document  number, 
which  is  composed  of  the  activity's  Unit  Identification  Code  (ETC),  the  4-digit  Julian 
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Figure  2.4    Ammunition  Master  Stock  Record  Card. 
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date,  and  a  4-digit  serial  number.  The  serial  numbers  are  assigned  sequentially  and  the 
recommended  range  is  8000  to  S999.  They  may  then  repeat,  however  used  in 
conjunction  with  the  Julian  date,  a  requisition  can  be  uniquely  identified.  See  Figure  2.5 


M00253      6123         8125 

l____l  II  I _J 

UIC     julian  serial 
date    number 

i | 

Document  Number 


Figure  2.5     Document  Number. 

Reclassification  of  onboard  inventory  items  may  occur  when  SPCC,  or  the 
Inventory  Manager  or  Technical  Manager,  determines  that  a  particular  lot  of 
ammunition  should  be  suspended,  used  in  a  limited  fashion,  or  considered 
unserviceable.  Fleet  users  are  notified  of  such  changes  by  Notices  of  Ammunition 
Reclassification  (NAR)  messages.  Approximately  annually,  all  effective  NAR's  are 
incorporated  into  NAVSEA  Publication  TWO24-AA-ORD-010,  Ammunition  - 
Unserviceable,  Suspended,  and  Limited  Use  [Ref.  13].  A  particular  item's  degree  of 
serviceability  is  described  by  its  one  character  Condition  Code,  all  of  which  are  fully 
discussed  in  Appendix  C  to  Reference  13  . 

On  the  Master  Stock.  Record  Card,  the  on-hand  balances  are  subdivided 
among  the  various  condition  codes  that  the  activity  holds  for  a  particular  NALC. 
Condition  Code  Alpha,  unrestricted,  is  naturally  the  most  common. 

The  Naval  Sea  Systems  Command  (NAVSEA)  publishes  allowance  lists  for 
each  vessel  which  depend  on  its  type  and  configuration.  The  lists  contain  ammunition 
type  and  quantity  authorized,  as  well  as  the  quantity  of  certain  NALCs  that  may  be 
used  for  training.  The  master  record  card  is  used  to  record  these  numbers  and  the 
computed  unexpended  training  allowance  remaining  for  the  fiscal  year. 

Any  changes  in  quantities  or  condition  codes  require  that  an  Ammunition 
Transaction  Report  ^ATR)  be  submitted.  This  report  will  be  more  fully  described  later. 
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but  the  Master  Stock.  Record  Card  is  used  to  associate  the  ATR  number  with  the 
particular  transaction  line  item  on  the  card. 

Finally,  various  other  codes  are  recorded  on  the  card  which  are  obtained  from 
one  of  several  references: 

1.  Packaging  Remarks:  References  12  or  14 

2.  Logistics  Code-NALC:  References  12  or  14 

3.  COG-Ccgnizance  Symbol:  Reference  12 

4.  MCC- Material  Control  Code:  Reference  12 

5.  DOT-Department  of  Transportation  Hazardous  Material  Code:    Reference  14 

6.  NHEEW-Xet  Explosive  Weight:  References  12  or  14 

7.  C.G.  Haz.  CI. -Coast  Gaurd  Hazardous  Material  Class   :  Reference  14 

2.  Lot/ Location  Card 

The  Ammunition  Lot  Location  Card.  NAVSUP  Form  1297,  Figure  2.6  , 
is  completed  for  each  lot  number  within  a  NUN.  There  are  only  a  few  new  concepts  on 
this  card  that  have  not  been  previously  explained,  so  the  explanation  will  be  brief.  The 
consignor  consignee  is  the  shore  activity  or  operating  unit  to  which  the  issue  was  made 
or  from  which  the  item  component  was  received.  This  card  contains  much  information 
previously  entered  on  the  Master  Stock  Record  Card. 

3.  Serial/ Location  Card 

The  Ammunition  Serial/Location  Card,  NAVSUP  Form  1356.  Figure  2.7  .  is 
completed  for  items  that  require  SLIT  tracking.  Serial/Lot  Item  Tracking  (SLIT)  is  a 
system  whereby  certain  ammunition  items  are  designated  for  increased  tracking  and 
surveillance.  These  items  may  require  identification  by  lot  number,  serial  number,  or 
both  when  reporting  transactions.  This  distinction  is  indicated  by  the  Material  Control 
Code  (MCC): 

MCC  Reports 

B  Lot  Number 

C  Item  Serial  Number 

E  Lot  and  Item  Serial  Number 

Items  that  do  not  require  SLIT  reporting  will  not  have  an  MCC  assigned.  MCC  Bravo 
ammunition  is  adequately  documented  on  the  Lot:  Location  Card.  Items  with  MCC 
Charlie  and  Echo  require  individualized  tracking  with  the  Ammunition  Serial;  Location 
Card. 
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Figure  2.6    Ammunition  Lot'Location  Card. 
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Ammunition  Serial/ Location  Card. 
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The  only  new  item  here  is  the  Maintenance  Due  Date  (MDD),  which  is  the  month  and 
year  of  the  component's  next  scheduled  maintenance.  MDD's  are  assigned  to  MCC 
Charlie  and  Echo  items  only.  Figure  2.8  may  help  to  illustrate  the  relationships 
between  the  various  stock  cards. 

4.  Discussion  of  Inventory  Record 

As  Figure  2.S  demonstrates,  normally  2  and  occasionally  3  of  the  stock  record 
card  types  are  required  to  describe  an  ammunition  item.  With  no  other  device 
available,  the  Master  Stock  Record  Card  must  hold  all  the  transaction  information  for 
even."  transaction  (i.e..  document  number,  type,  quantity,  etc.).  It  must  hold  all  of  the 
allowance  information,  or  you  would  have  to  reference  the  Allowance  List  each  time 
you  needed  that  information.  It  holds  much  generic  data  about  the  item  which  does 
not  change  regardless  of  transactions  or  quantity  in  the  inventory.  The  alternative 
however  would  be  to  look  up  information,  each  time  you  were  interested,  in  at  least 
four  very  voluminous  publications. 

The  Lot  Location  card  subdivides  each  NUN  by  lots,  and  much  information 
is  repeated.  The  only  new  data  items  are  the  lot  numbers.  The  Serial  Location  cards 
likewise  duplicate  data. 

It  is  quite  obvious  that  maintaining  all  the  required  records  for  even  a  small 
ship's  inventory,  say  at  least  40  NALCs,  would  be  extremely  tedious.  A  large  vessel 
with  perhaps  hundreds  would  demand  full  time  attention.  It  is  this  author's  experience 
that  much  of  the  repetitive  information  would  not  get  entered  properly,  and  the  initial 
construction  of  a  set  of  cards  would  be  an  onerous  task.  Multiplying  those  man-hours 
for  all  the  ships  involved  results  in  considerable  non-operational  training  time. 

Ideally  the  inventory  records  should  contain  information  that  deals  only  with 
that  particular  batch  of  ammunition,  namely: 

1.  NUN  -  what  is  it? 

2.  Condition  Code  -  what  can  it  be  used  for? 

3.  Activity  Classification  Code  -  who  is  it  for? 

4.  Quantity  -  how  many  are  there? 

5.  Storage  Location  -  where  is  it? 

6.  MDD  -  when  does  it  need  maintenance? 

7.  Lot  Number  -  what  lot  is  it? 

S.     Serial  Number  -  which  one  is  it? 
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This  information  can  not  be  looked  up  in  a  publication  because  it  deals  with  the 
particular  articles  at  hand.  Other  information  listed  on  the  stock,  cards  is  of  general 
nature  and  can  be  looked  up.  indicating  that  we  could  locate  it  in  one  central  place  and 
reference  it  when  needed.  Therefore  we  would  not  have  to  repeat  it  on  every  card.  This 
is  one  of  the  important  concepts  of  automation  that  can  be  used  in  many  ways  as 
chapter  3  will  demonstrate. 

B.       REQUISITION.  TURN-IN/TRANSFER,  RECEIPT 

1.  Background 

Naval  vessels  are  required  to  maintain  100%  of  their  authorized  allowance  on 
board  or  on  order,  so  as  to  be  ready  for  immediate  combat  operations.  Certain 
exceptions  apply  which  are  spelled  out  in  the  SPCC  CAIMS  manual  [Rcf.  3:  p.  8-2-2]. 
and  may  be  modified  by  fleet  commander  instructions  [Ref.  4,5].  Reasonableness 
dictates  how  small  an  order  should  be  placed  to  satisfy  these  requirements,  of  course, 
where  ammunition  is  concerned,  too  much  is  better  than  not  enough! 

A  few  more  definitions  are  appropriate  at  this  point.  Activity  Classification 
Codes  (ACC)  describe  basically  who  the  ammunition  is  for.  It  may  be  carried  by  a  ship 
to  satisfy  its  own  offensive  and  defensive  armament  needs,  in  which  case  it  is  ACC 
Alpha  ammunition.  However,  other  ammunition  could  be  carried  for  embarked 
Marines,  aviation  units,  or  for  underway  replenishment  of  other  ships.  Each  of  these 
other  recepients  causes  the  ACC  to  be  different.  Most  medium  to  small  ships  and 
submarines  only  carry  ammunition  for  their  own  use,  but  most  large  ships  have 
ammunition  on  board  for  other  purposes  and  thus  they  must  account  for  it  separately 
(ie-  a  separate  deck  of  inventory  cards).  This  makes  the  ACC  an  essential  data  element 
for  each  ammunition  record.  Chapter  8  of  the  CAIMS  manual  [Ref.  3:  p.  8-5-34],  lists 
and  describes  all  of  the  ACC  codes. 

Associated  with  the  concept  of  ACC,  are  the  three  types  of  allowance  lists  a 
ship  may  have.  A  Shipfill  Allowance  List  authorizes  the  quantities  and  types  of 
ammunition  for  own  ship's  use.  A  Mission  Load  Allowance  List  is  that  ammuniton 
carried  to  support  associated  ships  or  aircraft  squadrons;  usually  aircraft  carriers  and 
tender  type  ships.  A  Cargo  Load  Allowance  List  is  normally  held  by  designated  cargo 
or  logistic  type  ships  (  AE,  AOE,  AOR,  etc.)  for  replenishment  of  other  vessels. 

All  naval  vessels,  as  well  as  the  other  services  and  many  government  agencies, 
submit  requisitions  and  transaction  reports  in  Military  Standard  Requisitioning  and 
Issue    Procedures   (M1LSTRIP)    format   [Ref.  3:  Chapter   8].     This   system   serves    to 
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standardize  procedures  for  efficiency  and  economy.  It  allows  machine  readable  logistics 
traffic  by  specifying  data  elements,  codes,  and  formats.  Until  recently,  transaction 
reporting  was  done  in  normal  narrative  message  format  which  had  to  be  transcribed  to 
MILSTRIP  format  at  a  shore  activity  with  ADP  capability.  New  instructions  from 
SPCC  [Ref.  3],  and  those  still  in  production  at  fleet  headquarters,  now  direct  a  format 
that  is  machine  readable,  reducing  the  chance  of  error  in  transcription  or  key  punching. 
SPCC  is  linked,  via  ADP  equipment  and  telecommunications  with  all  major  stock 
points,  many  minor  stock  points,  and  other  logistics  organizations.  Ships  submit 
manual  requisitions  or  send  messages  which  are  entered  into  the  CAIMS  at  a  shore 
activity. 

The  Defense  Automatic  Addressing  System  (DAAS),  with  primary  location  in 
Dayton.  Ohio,  is  a  telecommunications  system  which  was  designed  to  effectively  route 
logistics  traffic  from  all  the  services.  DAAS  computers  can  receive  messages,  perform 
some  format  error  checking,  determine  the  addresses,  and  route  them  over  the  quickest 
path  to  their  destination.  DAAS  functions  over  the  Automatic  Digital  Network 
<  AL'TODIN).  The  message  format  that  is  acceptable  to  DAAS  is  slightly  different,  and 
the  requirements  for  use  more  restrictive,  than  a  normal  naval  message.  However  when 
applicable,  it  is  the  most  efficient  way  to  route  logistics  traffic.  The  SAMS  system 
should  allow  for  transmission  in  either  format  as  well  as  manual  requisitioning. 
2.   Requisitioning 

Ships  and  other  naval  units  may  submit  requisitions  for  conventional 
ammunition  in  one  of  three  formats  as  previously  alluded  to.  A  manual  requisition. 
DD  Form  1343.  Figure  2.9  ,  may  be  completed  and  physically  delivered  or  mailed  to  a 
shore  weapons  facility.  The  shore  activity  enters  the  requisition  into  the  CAIMS  with 
their  ADP  equipment,  SPCC  routes  the  requisition  to  the  appropriate  Inventory 
Manager  (SPCC.NAVAIR,NAVSEA,NMWEA.JCMPO).  and  an  appropriate  stock 
point  is  selected  to  deliver  the  material. 

A  message  requisition  may  be  prepared  in  DAAS  format.  Figure  2.10  ,  and 
electrically  transmitted.  A  requisition  line  item  on  a  DAAS  message  is  printed  on  one 
horizontal  line  or  66  characters,  with  no  separations.  A  DAAS  message  may  also 
contain  followup  actions,  modifications,  cancellations  and  other  logistics  actions 
besides  requisitions.  The  type  of  action  is  determined  by  the  document  identifier, 
column  1-3.  The  Routing  Identifier  <R  I),  column  4-6.  is  analyzed  and  the  line  item 
sent  to  its  addressee.  In  this  format  the  requisition  is  fully  machine  readable. 
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Figure  2.9     Manual  Requisition  Document. 
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3  U  3  J 


h  n  °  '     U  S  3  YOUR  SHIF 

T0     DAAS  DAYTON  OH 
INFO:    CINCLANTFLT  NORFOLK  VA 
WPNSTA  CHARLESTON  SC 
AMMO  MIL5TRIP  RE2N 


AODNCBW13  2000933  3  321   EAO 0  575V 2345611303009 RN12345JY6R2T876132192C 


Figure  2.10     DAAS  Message  Requisition  Format. 
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DAAS  has  restrictions  however.  There  can  be  no  narrative  remarks,  the 
classification  must  be  UNCLASSIFIED,  and  the  RT  must  be  a  continental  L'nited 
States  (CONUS)  activity  connected  to  ALTODIN.  Usage  of  DAAS  by  afloat  units  is 
somewhat  limited  by  fleet  commander  instructions  which  require  narrative  remarks  and 
primary  addressee  other  than  DAAS,  Dayton,  Oil  on  some  ammunition  items. 

The  last  requisition  format  is  the  normal  narrative  naval  message,  Figure  2. 1 1 
.  It  should  be  noted  that  information  and  codes  present  on  any  of  the  three  formats  are 
almost  identical.  Fleet  commander  instructions  require  some  minor  format  changes. 
The  Pacific  Fleet  Conventional  Ordnance  Management  Manual  [Ref  4:  p.  1-1-A-S]  for 
example,  requires  that  the  quantity  and  NSN  be  spelled  out  on  naval  message 
requisitions  to  prevent  confusion  in  the  event  of  a  garbled  message.  In  any  case,  this 
format  is  net  machine  readable  and  must  be  entered  into  CAIMS  at  a  shore  activity.  It 
is  more  flexible  however  than  a  DAAS  formatted  message.  Remarks  may  be  included, 
it  may  be  addressed  to  any  activity,  and  it  may  contain  classified  information  (  the 
remarks  generally  are  the  only  classified  information). 

The  three  formats  are  reasonably  well  described  [Ref.  3:  Chapter  8].  The 
codes  are  rather  cryptic  and  their  full  names  are  shown  below.  Explanations  may  be 
found  in  Appendix  B,  the  Data  Dictionary. 


TABLE  1 
MISCELLANEOUS  REQUISITION  CODES 

Code  Full    Name 

D/I(Doc.  I dent. )      Document  Identifier 

R/I  Routing  Identifier 

M&S  Media  and  Status  Code 

Serv  Service  Code 

Dem  Demand  Code 

Sig  Signal  Code 

Fund  Fund  Code 

Dist  Distribution  Code 

Proj  Project  Code 

Pri  Priority  Code 

RDD  Required  Delivery  Date 

Adv  Advice  Code 
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Unclassified  E  x  a  m  d  1  e 


f-HOM    CTF  SEVEN  THREE 

TO    SPCC  MECHANIC3BURG  PA 
INFO:    CINCFACFLT  PEARL  HARBOR  HI 

C0MNA73EAS YSCOM  WASHINGTON  DC 

COMSEVENTHFLT 

COMFAI  RWESTPAC  ATSUGI  J  A 

USS  CONSTELLATION 

USS  SHASTA 
CONFIDENTIAL   //N08010// 
AMMO  MILS  TRIP  REQUISITION 
A.    USS  CONSTELLATION  092106Z  JUN  90 

1.   (U)  A01/NC3/W/LW3 5 00890134/E A /00005/R03 364/0160/8001/ 
R/N6  2807/J/Y6/0  2E/884/06/174/2B 

a:;  NCB  W/M6810C24  5  2961/EA/00002/R03  364/0160/8002/R/N62807/ 
J/Y6/02E  3  21  :  : .  ? 9 9 

:-.'.:     •::=  H  E43800409I727  EA/30102/RC3 364/0160/8C0 3/R/BLNK/ 
S  .    D2E/835/06  1  "  4 
.-.  1  1  :.Z=    W/19790C4881027/EA  3D001/R0 3 364/0160/8004/R/N6 2807/ 

:  -,-.    376  D€  ; " :  zi 


Unclassified  Example 


Figure  2.11     Naval  Meassage  Requisition  Format. 


29 


3.  Turn-in/Transfer 

Ships  often  have  to  turn-in  ammunition  that  is  excess,  reclassified  by  NARs, 
or  requiring  periodic  maintenance  ashore.  The  DD  Form  1348-1  is  used  for  this 
purpose.  Figure  2.12  .  Somewhat  fewer  coded  items  are  necessary  on  this  form  because 
the  ship  is  physically  delivering  the  material  to  another  activity.  Most  commands  also 
select  another  group  of  serial  numbers  for  turn-ins,  in  order  to  differentiate  them  from 
requisitions.  A  separate  log  is  maintained.  The  CALMS  manual  [Ref.  3:  p.  8-3-1], 
assists  the  user  in  completing  the  form. 

4.  Receipt 

Ammunition  is  also  received  on  DD  Form  1348-1.  The  document  number  on 
the  receipt  document  corresponds  to  the  receiving  ship's  requisition  document  number. 
of  course  the  possibility  of  being  sent  material  that  was  not  ordered  exits.  The  only 
new  data  items  that  have  not  been  previously  discussed  are  the  unit  price  and  the  unit 
of  issue,  both  of  which  are  listed  in  the  Stock  List  of  Navy  Ammunition  [Ref.  12]. 

5.  Discussion 

The  requisition,  turn-in'transfer,  and  receipt  documents  require  some  form  of 
logs  to  be  kept.  A  Requisition  Log  may  contain  a  history  of  requisitions  and  receipts 
by  document  number  (serial  number).  A  Turn-in  log  would  be  similar.  Retention  of 
these  documents  provides  a  source  of  information  for  the  future,  instead  of  having  to 
look  up  the  information  all  over  again.  This  is  not  necessarily  a  good  practice  as 
certain  data  elements  may  have  changed  in  the  interim.  But  this  is  just  the  kind  of 
thing  a  busy  sailor  might  do  to  save  time,  not  recognizing  the  potential  problems 
involved.  Recall  of  the  many  different  data  items  from  publications  can  be  time- 
consuming. 

C.       AMMUNITION  TRANSACTION  REPORTING 

Transaction  reporting  is  required  for  any  action,  event,  or  procedure  that  results 
in  the  receipt,  issue,  transfer,  expenditure,  loss,  gain,  reconfiguration  or  change  in 
material  condition  of  reportable  material.    [Ref.  3:  p.  S-4-3]. 

The  format  of  Ammunition  Transaction  Reports  (ATR's)  has  recently  been  changed  to 
allow  optical  scanning  of  the  data  elements  which  are  separated  by  from  one  to  four 
slashes,"/".  ATR's  have  multiple  formats  depending  on  the  type  of  transaction,  the 
MCC  of  the  material  (i.e.,  SLIT  or  non-SLIT),  and  the  actual  type  of  the  material. 
This  extreme  variability  has  traditionally  caused  the  greatest  problem,  resulting  in  a 
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Fieure  2.12     Manual  Turn-in  Document. 
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high  error  rate  for  these  documents.  Although  the  new  format  is  more  efficient  in  that 
it  can  be  optically  read  and  entered  into  the  CA1MS  by  shore  activities,  it  is  now 
incomprehensible  to  the  fleet  user.  Therefore  each  ATR  must  be  created  in  a 
painstaking  step-by-step  manner,  minding  the  format  and  content  of  each  data 
element.  ATR's  are  transmitted  as  naval  messages  to  SPCC.  with  information 
adcrcssces  and  classification  depending  on  the  type  of  ordnance  and  the  type  of 
sending  platform  (i.e..  submarine,  surface  vessel  ').  Figure  2.13  illustrates  one  format  of 
ATR.  The  serial  numbers  run  from  001  to  999  and  then  repeat,  with  a  ship's  most 
recent  ATR  indicated  in  the  current  ATR's  reference  line.  This  is  to  ensure  that  SPCC 
receives  all  ATR's  from  a  ship  without  ommission.  and  in  the  correct  sequence.  Again, 
multiple  transactions  can  be  listed  on  one  message  as  long  as  the  common  information 
in  the  header  applies  to  ail  the  transaction  line  items.  Figure  2.14  attempts  to  illustrate 
the  various  ATR  formats,  the  variability  is  evident.  Each  vessel  keeps  an  ATR  log  to 
form  the  primary  history  of  the  ship's  ammunition  transactions,  from  overhaul  to 
overhaul,  and  to  allow  correction  of  any  ATRs  that  were  submitted  with  incorrect 
data.  This  log  may  consist  of  all  the  actual  messages  and  a  summary  of  each  ATR  with 
its  effect  on  the  running  total  of  each  item  involved. 

Properly  submitted  ATRs  are  critical  for  the  overall  functioning  of  CAIMS.  The 
old  adage  "  garbage-in,  garbage-out  "  aptly  applies,  and  it  is  sincerely  hoped,  by  all 
levels,  that  higher  echelons  are  not  making  procurement  and  allocation  decisions  based 
on  incorrect  data. 

D.       COMMENTS 

In  addition  to  comments  made  throughout  this  chapter  concerning  data 
redundancy,  multitudes  of  codes,  and  more  than  a  few  reference  publications,  mention 
should  be  made  of  the  lack  of  any  standardized  record  keeping  procedures. 
Requisitions,  turn-in  documents,  and  ATRs  must  be  submitted,  and  inventory  cards 
maintained,  but  no  system  or  procedures  exist  for  the  maintenance  of  logs  or  records. 

It  is  generally  accepted  that  some  sort  of  auditable  system  must  exist  to  resolve 
discrepancies  and  maintain  accountability.  The  procedures  that  each  individual  ship 
creates  may  range  from  excellent  to  poor.  Some  ships  may  have  even  written  ship's 
instructions  for  this  purpose,  detailing  the  manual  methods  to  be  used.  A  software 
package,  such  as  the  proposed  SAMS,  will  have  several  benefits  besides  more  accurate 
and  timely  ATRs.  It  will  keep  all  logs  and  records  for  the  user,  it  will  standardize 
procedures  without  requiring  the  user  to  create  new  logs  and  binders,  and  finally  it  will 
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Unclassified  E  x  a : 


NBA' 


FROM     0S5  SARATOGA 

TO     SPCC  MECHANICSBURG  PA 

INFO:    AS  REQUIRED  BY  SPCC  AND  FLEET  INSTRUCTIONS 
C     0  N  F  I  D     E  N  T  I  A  L    //N08015// 
SUBJ:    AMMO  TRANS  RPT  SPCC  8010-12 
////03 360/08 4/D/ 166/09 74 5/// 

///A6590093S6171/A / 31000  0/F5000//T5000/// 
///A590005420405/A//B20000//F1200//T18800/// 


Unclassified  Exanpie 
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Figure  2.13    Ammunition  Transaction  Report  (example). 
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Figure  2.14    Ammunition  Transaction  Report  Formats. 
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all  fit  on  a  disk  or  diskettes.  It  might  even  save  a  few  nervous  breakdowns  when  new 
Weapons  Officers  report  onboard  to  find  no  system  in  existence  at  all. 
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III.  AN  AUTOMATED  SYSTEM  DEVELOPEMENT 

The  purpose  of  Chapter  II  was  to  give  the  reader  a  basic  knowledge  of  the 
records  and  reports  presently  used  onboard  non-automated  ships  of  the  Navy  for 
conventional  ammunition  inventory  control  and  accountability.  Problems  of  data 
duplication,  lack  of  standardized  record  keeping  procedures,  data  inaccessibility,  and 
late  and  inaccurate  external  reports  as  a  result  of  these  were  discussed.  This  chapter 
shall  develope  a  database  management  system  (DBVIS)  solution  to  illeviate  those 
problems  as  well  as  reduce  the  administrative  burden  on  ship's  force  personnel. 

A.       METHODOLOGY 

It  is  now  generally  accepted  that  systems  analysis  and  design  must  follow  an 
orderly,  logical  process  to  arrive  at  a  system  that  is  reliable,  maintainable,  efficient,  and 
manageable  (i.e.  within  cost  and  time).  The  Shipboard  Ammunition  Management 
System  (SAMS)  de\eiopement  has  followed  such  a  process  with  certain  modifications 
that  reflect  the  new  technologies  of  the  DBMS  and  its  easy  to  use  programming 
language. 

Structured  analysis  and  design  evolved  in  the  I970's  to  bring  a  disciplined 
approach  to  computer  system  developement.  The  1950s  and  1960's  were  characterized 
by  haphazard  analysis  and  design  techniques  and  what  Meilir  Page-Jones  referred  to  as 
the  "Instant  Karma"  approach  of  computer  system  developement  [Ref.  15:  p.  27]. 
Many  excellent  books  now  exist  on  the  subject  of  structured  techniques, 
[Refs.  15,16,17],  so  the  treatment  here  will  be  brief  and  only  as  it  relates  to  the  SAMS 
developement.  Davis  [Ref.  17:  p.  8]  defines  the  steps  involved  in  a  structured 
developement,  or  life  cycle  as: 


Problem  Definition 
Feasibility  Study 

3.  Analysis 

4.  System  Design 

5.  Detailed  Design 
6  Implementation 
7.      Maintenance 
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The  relative  weight  that  each  step  carries  and  the  time  spent  in  each  area,  of 
course  depend  on  the  project  at  hand.  Most  organizations  use,  or  have  used,  some 
derivative  of  this  basic  life  cycle  in  their  system  developement  process.  A  reasonable 
approach  is  to  study  the  available  structured  developement  philosophies,  modify  these 
where  adviseable  to  accomadate  new  technologies  and  tools,  and  apply  the  best 
composite  plan.  There  have  been  worries  among  structured  technique  advocates  that 
the  new  technologies,  i.e.  fourth  generation  languages,  prototyping  packages,  and 
personal  computers,  will  compnmise  advances  made  in  systems  analysis  and  design. 
3ut.  as  Edward  Ycurcon.  a  prime  advocate  of  the  structured  techniques,  points  out: 

The  major  philosophical  concepts  used  to  build  reliable,  maintainable 
■information  systems,  which  is  what  the  structured  techniques  are  all  about,  can 
continue  to  embrace  new  technologies  without  destroying  the  concepts 
themselves.    [Ref.  16:  p.  6j 

Chapters  I  and  II  went  into  some  detail  on  the  nature  of  the  problem  and 
defined  the  scope  of  the  solution.  A  formal  feasibility  study  was  not  conducted, 
however  the  major  points  of  such  a  study  were  considered  [Ref.  17:  p.  274]: 

1.  Technical:  Can  the  system  be  implemented  with  current  technology? 

2.  Economic:    Do  the  benefits  outweigh  the  costs? 

3.  Operational  or  Organizational  (Political):  Can  the  system  be  implemented  in 
this  organization? 

Technical  feasibility  is  well  assured.  Inventory  control  systems  are  not  new.  the 
data  and  reports  required  are  well  defined,  and  the  DBMS  products  make  the  task  less 
difficult. 

Economic  feasibility,  as  usual,  is  hard  to  quantify.  How  much  is  a  10  per  cent 
increase  in  system  accuracy  worth  to  Navy  planners  responsible  for  ammunition 
procurement  and  allocation?  Also,  how  much  is  the  reduction  in  administrative  burden, 
and  the  subsequent  increase  in  operational  readiness,  worth?  These  are  difficult 
questions  to  answer.  In  light  o[  the  relatively  minor  expense  of  the  SAMS 
developement  however,  it  only  makes  sense  to  pursue  an  alternative  to  the  present 
manual  system.  If  the  project  progresses  beyond  the  research  stage  to  fleet 
implementation,  the  increased  costs  would  warrant  a  more  formalized  cost  benefit 
studv. 
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Political  feasibility  should  pose  no  problems.  Weapons  and  operations  personnel 
on  most  Navy  ships  are  already  heavy  users  of  computers  in  their  daily  routines.  Any 
labor  saving  device,  which  reduces  records  as  well,  would  most  likely  be  welcomed. 

B.       ANALYSIS 

The  analysis  phase  of  a  project  must  fully  determine  what  the  system  must  do. 
How  this  is  physically  accomplished  is  the  subject  of  the  next  section  on  design.  For 
this  author,  the  analysis  phase  began  in  1983,  unknowingly,  with  experience  operating 
the  manual  system,  which  is  largely  unchanged  today.  However,  under  the  pressure  of 
multiple  jobs,  most  users  generally  never  acquire  the  big  picture  that  is  necessary  to 
design  an  automated  system.  Normally  the  analyst  will  interview  many  people  involved 
in  different  phases  of  the  operation,  plus  review  all  the  applicable  documentation,  to 
gain  this  big  picture.  This  project  required  a  slightly  different  approach.  The  author 
acted  as  an  expert  user  analyst  and  based  on  experience  and  intense  study,  the  system 
was  designed  and  partially  implemented.  The  pitfall  here  is  that  the  expert  user  is  too 
"expert"  to  really  appreciate  user  difficulties.  These  difficulties  would  have  to  be 
resolved  by  a  period  of  "normal"  user  interaction  in  the  fleet  following  complete 
implementation.  It  will  be  shown  that  a  DBMS  makes  such  modifications,  as  may  be 
necessary  to  suit  the  bulk  of  the  users,  much  easier  to  perform. 

A  complete  knowledge  of  the  existing  system  was  the  first  major  job  in  the 
SAMS  developement.  Information,  publications,  instructions,  reports,  and  forms  were 
collected  from  all  the  commands  and  agencies  involved  in  the  flow  of  conventional 
ammunition  to  the  fleet.  The  intent,  policies,  and  procedures  of  the  CAIMS  program 
were  studied  to  gain  this  big  picture,  even  though  many  details  did  not  directly  affect 
the  end  user  environment.  There  are  several  "layers"  of  instructions  that  deal  with 
similar,  or  the  same  topics,  and  the  semantic  inconsistencies  between  these  often 
necessitated  phone  call  and  extensive  cross  referencing  to  resolve.  This  overlapping  of 
instructions  is  seen  by  this  author  as  a  definite  problem.  It  can  thwart  a  clear  end  user 
understanding  of  the  system,  since  they  have  little  time  for  phone  calls  or  extensive 
research. 

The  object  of  SAMS  is  to  automate  the  end-user  inventory  and  control 
procedures  while  remaining  compatible  with  requirements  of  higher  level  Navy 
instructions.  External  report  formats  must  be  as  described  in  Chapter  II,  however 
internal  stock  cards  would  not  be  used  in  an  automated  system  naturally.  This  would 
require  modifications  in  those  instructions  deleting  the  requirements  for  those  cards  for 
the  ^hips  that  are  automated. 
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1.  Data  Flow  Diagrams 

One  of  the  major  tools  of  structured  analysis  is  the  use  of  graphical 
representations  to  depict  information  flow.  Data  Flow  Diagrams  (DFDs)  are  a  network 
representation  of  a  system  which  is  generally  much  easier  to  understand,  at  least  by  the 
end-user,  than  the  functional  specifications  of  the  past.  The  DFD  is  an  analysis  tool. 
.  as  such,  is  logical  in  nature  and  does  not  depend  on  hardware,  software,  data 
structure,  or  file  organization.  A  logical  representation  is  one  that  reflects  a  user's  view 
of  the  system  and  it's  processes.  Several  references  [Refs.  15,17:  p.  60.281].  give  similar 
descriptions  of  the  constituent  parts  and  developement  of  DFDs.  Figure  3.1  shows  the 
Fundamental  System  Model  or  the  Context  Diagram  for  the  SAMS.  This  is  the  highest 
Level  of  abstraction  and  shows  the  entire  system  as  a  single  node.  The  user  inputs  data 
to  the  system  or  requests  processing  at  the  source  square,  the  system  node  performs 
the  necessary  processing,  and  outputs  data  and,  or  reports  at  the  sink  square.  This 
context  diagram  serves  as  a  starting  point  but  is  not  particularly  useful  or  informative. 
Subsequent  levels  of  refinement  form  a  complete  set  of  Data  Flow  Diagrams  for  the 
SAMS  and  are  included  as  Appendix  A. 


User 
Source 


Level  0 


User 
Sink 


Figure  3.1     SAMS  Context  Diagram. 

Data  Flow  Diagrams  do  not  show  flow  of  control  or  sequence  of  execution  of 
the  processes.  Also,  the  representation  of  files  are  purely  logical  and  may  be 
implemented  quite  differently  in  the  Final  design. 
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2.  Subsystem  Functional  Description 

Experience  and  research  provided  the  logical  divisions  for  the  conventional 
ammunition  management  problem.  Nine  subfunctional  areas  were  identified. 

1.  User  Access  Validation 

2.  Generai  Information,  Documentation 

3.  Inventor."  Allowance  Ammunition  Data 

4.  Transaction  Management 

5.  Requisition  Management 

6.  Turn-in  Document  Management 

7.  NARS  Management 
S.  System  Management 

9.     Generate  Internal  Reports 

This  system  breakdown  seems  obvious  on  the  surface  to  anyone  familiar  with  the 
manual  system,  as  well  it  should  be.  The  more  closeiy  an  automated  system  follows  the 
logical,  or  user's  view,  of  the  processes,  the  higher  probability  there  is  of  the  user 
feeling  comfortable  with  the  system.  However,  the  system  breakdown  also  considers  the 
system  goals  and  improvements  desired  in  the  automated  system  over  the  manual  one. 
a.    User  Access  j  Validation 

The  User  Access/Validation  function  should  ensure  that  only  authorized 
users  of  the  system  may  gain  access.  The  SAMS  is  intended  for  use  by  Weapons 
Department  personnel  charged  with  the  responsibility  for  ammunition,  and  as  such, 
they  should  be  the  only  people  manipulating  the  system.  Requests  for  system  data 
from  superiors  can  quickly  be  accessed  by  these  people.  The  system  should  be  capable 
of  controlling  authorized  user's  priveledges  within  the  system  also.  The  SAMS  only 
requires  two  basic  levels  of  access.  The  lower  level  should  allow  access  to  the  day-to- 
day processing  options,  two  through  seven  and  nine.  The  higher  level  will  allow  the 
SAV1S  administrator  or  manager  to  access  all  modules  for  system  initialization, 
infrequent  data  changes,  user  changes,  or  to  correct  unforeseen  system  processing 
problems.  This  degree  of  power  places  great  responsibility  on  the  administrator  and 
requires  that  he  be  fully  knowledgeable  of  the  system  and  the  consequences  of  his 
actions.  The  risk  in  this  approach  is  necessary  however,  because  there  will  be  no 
technical  representative  or  outside  help  if  the  system  developes  a  problem  while  at  sea. 
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b.  General  Information/ Documentation 

The  second  option  provides  general  information  and  documentation  that 
the  user  may  find  useful  in  getting  acquainted  with  the  system.  This  may  include  a 
system  description,  explanation  of  the  options  available,  what  the  system  does  not  do, 
hardware  requirements,  basic  keyboard  operations. etc..  Also,  this  option  should  give 
the  codes  and  definitions  that  are  frequently  used  by  the  SAMS  and  within  the  CAIMS 
s)  stem  as  a  whole.  A  data  dictionary  will  not  only  explain  the  many  acronyms  but  will 
increase  the  knowledge  of  the  user  and  assist  the  manager  in  system  management. 

Finally,  a  help  program  can  be  resident  within  this  option  and  called  from 
various  places  throughout  the  application  programs.  It  is  very  difficult  however,  to  give 
adequate  help  to  a  user  with  generic  help  messages  about  a  particular  question  he  may 
have.  The  author  feels  that  giving  more,  rather  than  less  information  in  the  user 
:;/.o:face  is  generally  less  frustrating  than  needing  to  frequently  use  a  help  program. 
Now.  if  the  program  was  in  constant  use  by  a  dedicated  operator  the  extra  verbage 
would  become  annoying,  however  that  should  not  be  the  case  here.  The  data  entry  to 
the  SAMS  would  probably  slow  down  an  operator  who  has  all  of  the  many  codes 
memorized,  but  for  those  less  gifted  i^the  majority),  the  system  will  minimize  the  time 
referencing  manuals.  Also,  the  instructive  goal  of  the  system  can  be  more  easily 
accomplished  in  this  manner. 

c.  Inventory)  Allowance  J  Ammunition  Data 

This  is  basically  a  review  option.  The  user  would  frequently  want  to  review 
the  current  status  of  his  onboard  inventory,  perhaps  with  a  quick  overall  perspective  in 
J  or  a  detailed  review  of  a  particular  item.  The  SAMS  inventor}'  information 
should  make  the  present  record  cards  unnecessary.  Since  the  change  in  an  inventory 
level  can  only  occur  as  the  result  of  a  transaction  of  one  kind  or  another,  the  inventory 
is  not  manipulated  directly,  but  is  updated  as  a  result  of  transaction  processing. 

Allowance  information  can  be  conveniently  stored  in  the  system  where 
training  expenditures  can  be  updated  and  monitored.  Again,  any  update  occurs  as  a 
result  of  transaction  processing. 

Ammunition  data  is  that  generic  information  about  a  particular  item  that 
does  not  change  as  a  result  of  transactions  and  previously  would  have  been  looked  up 
in  one  of  several  publications.  See  references  12  and  14  for  examples.  Any  amount  of 
information,  about  any  kind  of  ammunition,  could  be  loaded  into  the  system,  however 
to  save  disk  space,  only  those  items  the  particular  ship  would  likely  carry  should  be 
entered.  The  system  manager  can  add  or  delete  items  as  necessary. 
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d.  Transactions 

Transaction  Management  is  the  major  processing  function  of  the  system.  A 
unit  can  receive  items  through  a  receipt,  condition  code  change,  or  a  few  other 
infrequent  occurances.  It  can  reduce  stock  by  an  issue,  expenditure,  condition  code 
change,  or  other  reason.  This  subsystem  should  recognize  the  type  of  transaction, 
update  inventories,  create  the  information  that  will  go  on  the  ATR,  and  update  other 
files  when  necessary.  For  example,  a  receipt  transaction  should  update  the  requisition 
file  if  the  receipt  occured  as  a  result  of  a  requisition  the  ship  submitted.  An  expenditure 
transaction  should  update  the  Allowance  File  if  that  item  had  a  training  allowance. 

e.  Requisitions 

Requisition  Management  involves  the  creation  of  requisition  documents  in 
the  various  allowable  formats.  The  MILSTRIP  system,  dicussed  earlier,  is  heavily  code 
oriented,  and  this  option  should  guide  the  user  through  the  selection  of  the  proper 
codes  for  the  particular  item  at  hand.  This  module  should  also  store  the  information  as 
a  permanent  record,  eliminating  the  need  for  manual  records.  A  user  may  edit  these 
records  during  creation  and  prior  to  their  being  submitted,  however  the  integrity  of  the 
data  would  be  violated  if  he  were  allowed  to  do  so  afterward.  Therefore,  as  with  ATR's 
and  Turn-in  documents,  there  is  a  point  where  the  data  must  be  committed,  and  not 
changeable  by  the  user.  Any  special  cases  could  only  be  adjusted  by  the  system 
manager. 

/.    Turn-in  Documents 

The  Turn-in  Document  Management  function  must  create  and  store  the 
turn-in  record  and  print  the  DD  Form  1348-1,  the  Single  Line  Item  Release  Receipt 
Document.  The  processes  involved  are  very  much  like  the  requisition  management 
function;  one  representing  imminent  issue  and  one  representing  imminent  receipt. 
Later,  when  the  transaction  actually  occurs,  an  issue  transaction  can  be  processed 
which  updates  the  inventory.  Naturally,  the  information  already  recorded  by  the  Turn- 
in  processing  need  not  be  collected  again,  rather  the  Turn-in  file  is  linked  to  the 
Transaction  file  and  the  information  transferred. 
g.  NAR  Messages 

Naval  Ammunition  Reclassification  (NAR)  Management  serves  to  process 
these  messages  as  they  are  received.  A  stock  check  must  be  conducted  to  determine  if 
the  ship  holds  any  of  the  ammunition  lots  specified  in  the  message.  If  the  check  is 
negative,  the  only  action  required  is  to  log  the  serial  number  of  the  NAR  message.  If 
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the  stock  check  shows  that  action  is  required,  then  the  proper  reclassification 
transaction  must  be  processed.  The  information  pertinent  to  the  NAR  must  also  be 
saved  for  future  reference  and  historical  records.  There  should  also  be  a  link  between  a 
reclassification  transaction  and  the  XAR  message  that  precipitated  it. 

h.    System  Management 

The  System  Management  module  will  be  extremely  powerful,  allowing  the 
manager  to  globally  edit  all  files  and  initialize  the  system.  He  will  also  be  able  to 
manage  the  security  system,  archive  old  records,  recover  the  system  when  necessary 
from  backup  files,  and  have  access  to  the  operating  system  and  DBMS  dot  prompt. 
System  documentation,  of  no  real  value  to  the  normal  user,  will  be  available  to  the 
manager,  to  further  his  understanding  of  the  system. 

I.    Internal  Reports 

Lastly,  the  Generate  Internal  Reports  function  will  produce  those  reports 
that  the  typical  users,  and  their  supervisors,  would  find  useful  in  management  of  their 
conventional  ammunition  program.  Of  course,  the  information  would  also  be  available 
on-line,  but  it  is  often  useful  to  have  hard-copies.  Microcomputers  will  still  not  fit  in 
one's  back  pocket!  The  SAMS  should  be  flexible  enough  to  allow  future  report 
requirements  to  be  incorporated  without  system  redesign.  The  data  flow  diagram  for 
this  function  describes  several  of  the  anticipated  reports,  however  expansion  is 
probable  as  new  requirements  come  to  light.  User  experience  would  suggest  other 
useful  reports. 

3.  System  Data 

As  the  name  would  suggest,  a  data  flow  diagram  shows  the  data  that 
interfaces  the  active  processing  areas  of  the  system.  The  data  is  stored  in  files  for  later 
recall  or  processing.  A  convenient  way  to  aid  the  analysis  of  a  system  is  to  identify  the 
data  that  is  require  at  the  "sink"  and  work  backwards  through  the  system  to  the  source 
of  the  data.  The  SAMS  has  certain  data  elements  that  it  must  be  able  to  produce  to 
construct  ATRs,  requisitions,  and  turn-in  documents.  Also,  it  must  record  the 
inventory  data  to  replace  the  manual  stock  cards.  This  data  then  forms  the  minimum 
set  for  the  system.  Table  2  identifies  the  data  that  is  included  in  these  output 
documents  and  the  stock  cards. 

These  data  elements  thus  form  the  initial  inputs  to  a  Data  Element  Dictionary 
(DED).  A  DED  is  basically  a  collection  of  data  about  data.  The  idea  is  to  provide 
information  on  the  definition,  structure,  and  use  of  each  data  element  in  the  system 
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TABLE  2 
SAMS  OUTPUT  DOCUMENT  DATA  ELEMENTS 


Transaction  Report  Data  Elements 


From: 
Info: 


Name 

Info  Addresses 


Date  of  last 


;r/. 


or  last  ATR  DTG 
Own  ship  UIC 
ATR  Serial 

Activity  Class.  Code 
Julian  Date 

nun 

Beginning  Balance 
uantity 
ser  ID/Source  ID  Code 


Document  Number: 

Serv.  Desig.  Code 

UIC 

Julian  Date 

Serial 
Ending  Balance 
Lot  Number 

Component  Serial  Number(s) 
Maintenance  Due  Date 
Type  of  Maintenance  Due  Code 
Old  Condition  Code 
New  Condition  Code 
Transaction  Code 


Turn-in  Document  Data  Elements 


Stock  Number: 

FSC 

NUN 
Unit-of-issue 
Ouantity 
Document  Number: 

Serv.  Desig.  Code 

UIC 

Julian  Date 

Serial 
Distribution  Code: 

Monitoring  Activity 
Cognizance  Symbol 
Project  Code 
Unit  Price 
Shipped  from: 

Desig.  Code 


>erv. 

UIC 

Name 

Hull 


Number 


Ship  to: 

Serv.  Desig.  Code 

UIC 

Name 
Location/Hull  Number 
Total  Price 
Security  Risk  Code 
Material  Condition  Code 
DOT  Class.  Code 
C. G.  Hazard  Code 
Lot  Number 

Component  Serial  Number(s) 
NALC 

Noun  Name 
NAR  Number: 

NAR  Serial 
NAR  Year 
Date  Shipped  or  turned  in 
Freight  Class.  Nomenclature 
Type  of  Container 
No.  of  Containers 
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TABLE  2 
SAMS  OUTPUT  DOCUMENT  DATA  ELEMENTS  (CONT'D.) 


Requisition  Data  Elements 
Code 


Reauisitior.ee: 
"Serv.  Desig 
UIC 
Name 
Location/ 

Hull  Number 
Requisitioned 

Serv.  Desig.  Code 
UIC 
Name 

Hull  Number 
Document  Identifier 
Routing  Identifier 
Media  and  Status  Code 
Stock  Number: 
FSC 
NUN 
Unit-of- issue 
Quantity 


Inventory  Record 

Transaction  Jul.  Date 
Document  Number: 

Serv.  Desig.  Code 

UIC 

■Julian  Date 

Serial 
Transaction  Code 
Quantity 
Condition  Code 
ATR  Serial 

Unexp.  Trng.  Allowance 
Allowance 

S0%  of  Shipfill  Allow. 
Annual  Trng.  Allowance 


Docume 

Se 

U 

Ju 

Se 

Demand 

Suople 

*  Se 

UI 

Signal 

Fund  C 

Distri 

Mo 

Co 

Projec 

Priori 

Requir 

Advice 

Info 


nt  Number: 

rv.  Desig.  Code 

C 

lian  Date 

rial 

Code 
mental  Address: 
rv.  Desig.  Code 
C 

Code 
ode 

bution  Code: 
nitoring  Activity 
gnizance  Symbol 
t  Code 


ty  Code 

ed  Deli1 


very  Date 
Code 

Addresses 


Data  Elements 

NALC 

Cognizance  Symbol 

NIIN 

Material  Control  Code 

Activity  Class.  Code 

DOT  Class.  Code 

Net  Explosive  Weight 

Stowage  Location 

C. G.  Hazard  Code 

Consignor/Consignee  UIC 

Lot  Number 

Component  Serial  No.(s) 

Maintenance  Due  Date 


[Ref.  1":  p.  296].  Table  3  lists  the  format  of  the  information  that  will  be  stored  in  the 
DED  for  each  data  element.  By  exactly  defining  the  meaning  and  structure  of  the  data 
elements,  standardization  among  the  application  programs  is  facilitated.  Also,  as  will 
be  discussed,  relationships  between  data  can  be  utilized  to  greatly  increase  the  amount 
of  useful  information  the  system  can  produce.  This  can  only  be  accomplished  if 
consistent  data  definitions  are  observed.  The  DED  for  the  SAMS  will  be  an  on-line 
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facility  for  user  reference  and  may  also  be  printed  for  hard  copy  documentation. 
Appendix  B  is  the  SAMS  Data  Element  Dictionary. 

C.       DATA  ORGANIZATION 

1.  File  Processing 

A  final  consideration,  and  one  of  primary  importance,  is  the  manner  in  which 
the  system's  data  is  stored  and  represented.  Traditionally,  file  processing  systems 
organize  all  of  the  data  for  a  particular  specialized  application  into  a  single  file  and  the 
program  operates  on  that  file  to  produce  the  output.  In  this  manner,  the  file  is  really 
just  a  storage  medium  for  potentially  very  dissimilar  data.  No  data  organization  is 
implied  other  than  sequencing.  Other  specialized  application  programs  would  operate 
on  files  that  contain  all  of  the  data  necessary  for  that  application.  In  terms  of  the 
SAMS,  such  a  system  might  be  structured  as  in  Figure  3.2  . 

There  are  some  immediate  problems  with  this  method  of  file  and  data  organization  for 
an  ammunition  management  system.  First,  since  each  file  contains  all  of  the  data 
needed  for  it's  program,  there  is  much  redundant  data  in  the  system.  This  of  course 
requires  much  redundant  data  entry  which  the  operator  resents  because  he  logically 
questions  the  necessity  for  doing  it.  For  example,  each  of  the  files  in  Figure  3.2  ,  and 
their  associated  program,  require  the  name  of  the  ship  producing  the  documents,  and 
thus  the  files  must  contain  that  data.  This  type  of  redundancy  has  traditionally  been 
accepted  because  the  programs  that  would  be  required  to  share  data  among  files  were 
complex.  Unless  all  the  application  programs  and  files  are  constructed  with 
compatibility  in  mind,  a  conversion  process  between  different  record  formats  might  be 
necessary.  A  one-of-a-kind  request  necessitating  shared  data  would  have  to  be  vitally 
important  to  merit  such  efifort. 

This  lack  of  integration  capability  limits  the  information  that  can  be  obtained 
from  the  data.  However,  the  redundancy  of  data  also  presents  problems  other  than  the 
multiple  data  entry  required.  It  wastes  storage  space  in  the  files,  which  is  important 
when  considering  a  microcomputer  application.  The  larger  files  also  cause  slower 
processing  times  for  the  system  as  a  whole.  Finally,  when  data  elements  change,  the 
different  programs  must  all  be  updated  or  inconsistencies  will  result. 

2.  Database  Processing 

Database  processing  is  quickly  gaining  ground  on  file  processing  in  most  ADP 
applications  and  has  several  major  advantages  over  file  processing  techniques.  First 
and  foremost.  Data  Base  Management  Systems  (DBMS)  allow  the  sharing  of  data 
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TABLE  3 
DATA  ELEMENT  DICTIONARY  FORMAT 


Longtitle:   The  long  title  of  the  data  element. 
It  may  contain  up  to  30  characters. 


Name:   A  short  hand  version  of  the  long  title 

to  be  used  in  programming  and  is  compat- 
ible with  the  DBMS  variable  representation 
and  length  for  record  and  field  names. 
(  10  characters  for  field  names  and  8 
characters  for  record  names.  ) 


DEN:   (Data  Element  Number)  For  those  data 
elements  that  are  cataloged  in  the 
Standard  Data  Element  Dictionary( SDED) , 
a  DEN  is  assigned.  The  DEN  consists  of 
an  alphanumeric  character  followed  by 
three  or  four  numerics.  The  DEN  acts  as 
a  means  for  controlling  data  elements  and 
as  a  short  hand  name. 


Picture:   The  data  type  of  the  element, i.e. 

character , numeric,  logical,  etc.,  and 
the  width  of  the  field. 


Desc. :   The  narrative  description  explains 

what  data  or  information  the  element 
reoresents. 


Ref s.  :   Publications  and  other  documentation 

that  give  additional  information  about 
the  data  element. 


Codes:   If  the  data  element  has  codes  associated 
with  it,  the  reference  that  lists  all 
those  codes  and  their  meanings  is  given. 
(Most  codes  are  given  in  the  General 
information  option   1  . ) 


Used  in:   All  relations  in  which  the  data  element 
appears.  (SAMS  Relations) 
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Figure  3.2     File  Processing  System  for  SAMS. 

between  files  quickly  and  easily.  This  is  accomplished  by  the  DBMS  program  itself, 
which  is  usually  quite  complex,  but  fotunately  requires  the  user  to  know  nothing  about 
it's  intricacy.  Thus  the  system  files  are  established  under  DBMS  control  in  a 
compatible  format.  Application  programs  only  communicate  with  the  DBMS,  as  far  as 
data  retrieval  is  concerned,  and  it  "fetches"  the  desired  data  by  it's  own  means.  Sharing 
data  means  that  a  reduction  in  redundant  data  is  now  possible  through  intelligent  file 
design.  In  contrast  to  Figure  3.2,  Figure  3.3  is  a  representation  of  how  the  SAMS 
might  be  constructed  using  database  technology. 

A  DBMS  also  creates  program'data  independence  since  the  programs  do  not 
need  to  know  anything  about  the  data  structure  of  the  files.  We  can  add  application 
programs  that  use  any  of  the  files  and  this  gives  much  flexibility  in  system  design. 
Fields  can  even  be  added  or  deleted  from  the  files  without  any  effect  on  the  programs 
that  do  not  explicitly  use  the  affected  data. 

There  are  some  disadvantages  to  database  systems,  however  for  medium-to- 
small  applications,  with  much  interaction,  they  are  very  insignificant  [Ref.  IS:  p.  6]. 

The  SAMS  will  therefore  use  a  modern  commercial  database  package,  dBase 
III  Plus,  by  Ashton-Tate  of  Torrence,  California.  This  is  a  moderately  priced  package 
for  use  on  microcomputers  and  has  gained  much  popularity.  DBase  III  Plus  is  a 
relational  database  which  simply  means  that  data  is  represented  in  the  form  of  tables, 
or  relations.  Readers  interested  in  a  full  discussion  of  relational  database  theory  should 
refer  to  Date  [Ref.  19],  L'llman  [Ref.  20],  Kroenke  [Ref.  18],  and  Brodie  [Ref.  21]. 
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Figure  3.3     Database  System  for  SAMS. 

It  was  previously  mentioned  that  a  reduction  in  redundant  data  was  possible 
through  intelligent  file,  or  relation  design.  Good  design  consists  of  properly  matching 
the  data  elements,  or  attributes,  of  a  relation  so  as  to  prevent  data  integrity  problems. 
Wetherbe  and  Dickson  [Ref.  22:  p.  213]  describe  the  common  integrity  problems  as: 

1.  Difficulty  in  accurately  identifying,  locating,  or  updating  all  records  given  a 
specific  set  of  attributes. 

2.  Needlessly  repeating  fields  in  records,  therefore  requiring  redundant  storage  and 
updates. 

3.  Inconsistencies  among  data. 

•4.     No  records  within  which  to  store  certain  fields. 

The  process  of  normalization  is  a  set  of  rules  or  guidelines  which  help  a 
database  designer  build  relations  that  minimize  update  anomolies  and  data 
inconsistencies.  For  larger  systems  with  a  high  transaction  rate,  strict  compliance  with 
all  of  the  normalization  rules  can  lead  to  conflict  with  retrieval  performance  because 
normalization  generally  results  in  more  relations.  This  then  requires  more  effort  to 
retrieve  all  the  necessary  data.  The  SAMS  however,  will  be  a  relatively  small  system 
with  a  low  transaction  rate,  and  therefore  the  design  should  strive  for  maximum 
reasonable  normalization.  Excellent  descriptions  and  examples  ot^  the  normalization 
rules  are  given  in  Kroenke  [Ref.  18:  p.  2S6]  and  Kent  [Ref.  23]. 

There  are  seven  normal  forms  identified,  and  in  consideration  of  the  type  of 
data  involved  in  the  SAMS,  it  may  be  difficult  to  apply  higher  than  the  Boyce-Codd 
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normal  form  (BCNF)  in  most  cases.  Briefly,  the  guidelines,  or  rules  up  to  this  point 
are: 

1.  All  records  in  a  relation  must  contain  the  same  number  of  fields  and  none  must 
repeat.  This  is  basically  the  definition  of  a  relation  in  relational  database  theory. 

2.  The  second  normal  form  requires  that  all  non-key  attributes  are  dependent  on 
the  key.  A  key  is  one  or  more  attributes  that  determine  a  record. 

3.  Third  normal  form  is  satisfied  when  no  non-key  attribute  provides  a  fact  about 
another  non-key  attribute. 

4.  Boyce-Codd  normal  form  requires  that  every  attribute  that  provides  a  fact 
about  another  attribute  (determinant),  must  be  capable  of  being  a  key  for  the 
relation  (i.e.  a  candidate  key). 

Thus,  analysis  concludes  with  the  generation  of  DFDs,  the  functional 
descriptions,  identification  of  the  data  and  it's  structure,  and  consideration  of  the 
normalization  policies  for  the  database  relations. 
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IV.  SAMS  DESIGN 

The  design  of  the  database  relations  for  the  SAMS  is  a  critical  juncture  in  the 
de\  elopement  process.  For  the  reasons  discussed  in  the  previous  chapter,  thoughtful 
design  of  these  relations  will  ensure  the  flexibility  and  integrity  of  the  system. 

Relation  design  is  not  an  easy  task,  even  for  a  relatively  small  system  like  SAMS 
with  only  a  hundred  or  so  data  elements.  A  starting  point  is  to  logically  group  data 
elements  as  was  done  for  the  external  reports  and  stock  records  in  Table  2  .  We  must 
also  then  consider  the  data  elements  that  deal  with  generic  ammunition  information, 
allowance  lists,  NAR  messages,  addresses  of  other  Navy  units,  and  constant  data 
referring  to  a  particular  ship  (static  data).  If  we  assemble  these  lists  independently  of 
each  other,  there  is  much  data  duplication  which  must  be  minimized  for  the 
normalization  we  require. 

To  store  data  elements  in  one  relation,  yet  link  them  to  other  relations,  there 
must  be  common  attributes  between  the  two  relations.  However,  these  attributes  must 
be  unique  so  that  the  DBMS  can  locate  the  correct  record.  This  normally  requires  that 
the  relationship  be  established  to  a  key  attribute.  DBase  III  Plus  requires  that  the 
attribute  that  is  being  searched  for  be  an  "index"  of  the  relation.  An  index  is  a  file  that 
is  created  for  an  associated  database  relation  which  contains  a  particular  attribute  in 
alphabetical,  or  alphanumeric  order  and  its  associated  record  number  in  the  database. 
This  allows  the  DBMS  to  quickly  search  for  a  particular  value  of  an  attribute  in  the 
index  file  and  obtain  the  corresponding  record  number  in  the  database  file.  When 
records  are  added  or  deleted  from  a  relation,  only  the  indexes  are  reorganized  which 
could  save  considerable  time  in  a  large  database.  Moreover,  many  indexes  can  exist,  on 
different  attributes,  for  the  same  relation. 

With  these  considerations  in  mind,  the  SAMS  data  elements  are  separated  into 
appropriate  relations  and  indexed  as  deemed  appropriate  to  accomplish  the  file 
relationships  desired.  The  relation  structures  will  be  fully  described  with  regard  to 
normalization  in  the  next  section. 

Although  compatibility  in  data  elements  or  software  is  not  required  of  the 
SAMS,  as  it  is  a  stand  alone  system,  it  was  desired  that  data  elements  used  in  the 
CAIMS  be  used  by  SAMS  where  possible.   This  resemblence  would  minimize  any 
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difficulties  in  user  understanding  when  referring  to  supply  system  or  CALMS 
publications.  Also,  since  CAIMS  already  has  a  Data  Element  Dictionary  (SDED),  it  is 
a  question  of  not  "reinventing  the  wheel".  If  data  elements  in  this  dictionary  were 
directly  applicable  to  the  SAMS,  they  were  used.  Minor  modifications  in  data  element 
name  or  picture  were  necessary  in  some  cases  {COBOL  vs.  dBase  III  Plus  ),  but  the 
meanings  were  close  enough  to  assign  the  CAIMS  Data  Element  Number  (DEN)  to 
the  SAMS  element. 

Table  4  lists  the  conventions  used  in  selecting  the  SAMS  database  and  index 
names.  It  is  easy  to  see  that  some  sort  of  pattern  is  necessary  in  selecting  file  names, 
their  number  quickly  grows  beyond  human  memory.  Table  5  conveniently  lists  the 
database  files  and  their  associated  index  and  format  files.  A  format  file  is  constructed 
by  the  DBMS,  with  user  interaction,  to  create  custom  data  entry  screens.  Even  this 
relatively  small  system  is  composed  of  over  fifty  programs  and  fifty  files,  therefore 
program  and  file  directories  are  also  needed.  A  complete  program  directory  is  included 
as  Appendix  C. 

A.       SAMS  PHYSICAL  RELATION  DESCRIPTION 

Table  6  lists  the  physical  structure  for  all  of  the  SAMS  database  files.  It  would  be 
helpful  to  the  reader  to  refer  to  this  table  throughout  this  discussion. 

1.  Transaction  File  (ATR  File) 

This  file  contains  the  data  elements  that  relate  specifically  to  a  particular 
transaction.  The  key  in  this  file  is  the  ATR  serial  number  (ATRSERIAL).  To 
normalize  to  the  Boyce-Codd  Normal  Form  (BCNF),  every  determinant  must  be  a 
candidate  key,  and  the  only  key  here  is  the  ATR  serial  number.  Every  other  data 
element  should  furnish  a  fact  about  the  key,  and  only  the  key,  and  this  is  satisfied  with 
one  exception  mentioned  later. 

As  mentioned  in  Chapter  II,  ATR  numbers  run  from  001  to  999  and  then 
repeat.  It  would  take  quite  a  few  years  for  the  typical  ship  to  go  through  999  numbers. 
Repeating  key  elements  can  not  be  permitted  so  if  there  was  a  chance  of  this,  the  old 
records  would  be  archived.  Old  instructions  required  that  ships  restart  their  ATR 
numbers  when  "chopping"  (Change  of  Operational  Command)  to  another  fleet.  If  this 
situation  existed  on  a  ship  that  SAMS  was  to  be  installed,  the  old  fleet  numbering 
seqeunce  should  not  be  included  in  the  initialization  to  prevent  repeating  key  field 
values. 
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TABLE  4 

SAMS  FILE  NAMING  CONVENTIONS 

A. 

Da 

tabase 

Files  ( . dbf ) 

1. 

First 

two  letters  - 

system  prefix-  Ammunition 

Management  "AM" 

2. 

Third- 

-Eighth  letter 

-  description  of  file 

contents 

B. 

In 

dex  Fi! 

.es  ( . ndx) 

First 

two  letters  - 

system  prefix  -  Ammunition 

Management  "AM" 

2. 

Third 

letter  -  . dbf 

file  description 

a. 

Requisition  - 

"R" 

b. 

Ammunition  Data  -  "A" 

c. 

Transaction  - 

Tlrpl! 

d. 

Inventory  -  "I 

It 

e. 

Turn-in  -  "U" 

f. 

Allowances  -  ' 

w" 

g. 

NAR  Action  -  ' 

N" 

h. 

NAR  Serial  -  ' 

E" 

i. 

Static  Data  - 

none 

3- 

Address  -  "D" 

3. 

Fourth-Eighth  letter 

■  -  index  file  description 

C. 

Format  Files  ( . fmt) 

1. 

First- 

•Third  letter  - 

"ADD" 

2. 

Fourth-Eighth  letter 
contents 

•  -  description  of  .  dbf  file 
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TABLE  4 

SAMS  FILE  NAMING  CONVENTIONS  (CONT'D.) 

D.     Exceptions 

i. 

DBSYSTEM. db    -    User's    File    (encrypted) 

2. 

CONTFILE.dbf    -    Contains    File    -    Programs    <-> 
files 

.  dbf 

3. 

DATAELEM.  dbf    -    Data   Element    File 

4- 

DICFILES.dbf    -    Files   Directory 

5. 

PROGFILE. dbf    -    Programs    File 



The  ATR  Status  is  a  local  SAVIS  data  element  which  serves  to  indicate  the 
condition  of  a  particular  record.  A  transaction  can  be  incomplete,  ready  for 
submission,  or  submitted.  An  "incomplete  transaction"  is  one  in  which  the  user  has  not 
completed  entering  the  necessary  data  or  he  is  not  ready  to  say  the  data  is  correct.  This 
is  strictly  a  user  assigned  status  and  no  inventory  update  takes  place  based  on  an 
incomplete  or  blank  entry.  When  the  user  is  satisfied  that  the  data  is  correct,  he 
changes  the  status  to  "ready  for  submission",  and  inventory  update  takes  place.  At  this 
point  he  may  print  the  ATR  for  submission  to  the  Radio  Room  or  Communications 
Center,  however  he  may  not  edit  or  delete  the  record.  When  the  message  is  routed  back 
from  the  communications  personnel,  verifying  broadcast,  the  status  can  be  changed  to 
"submitted",  and  the  message  Date  Time  Group  (DTG)  entered.  The  DTG  may  be 
used  on  subsequent  ATRs  and  thus  must  be  retained. 

The  National-Item-Identification-Number  (NUN)  uniquely  identifies  a  type  of 
ammunition  and  can  therefore  be  the  link  to  the  Ammunition  Data  file  to  obtain  the 
Type  of  Maintenance  Due  Code  (TMDC).  The  TMDC  will  be  required  on  ATRs  that 
involve  Serial  Lot  Item  Tracking  (SLIT)  material. 

To  uniquely  identify  an  ammunition  item  that  is  or  was  physically  in  the  ship's 
inventory,  not  only  the  NUN,  but  the  Condition  Code  (CC),  Activity  Classification 
Code  (ACC),  Lot  Number,  and  Component  Serial  Numbers  (if  applicable),  are 
required.  Multiple  items  with  serial  numbers  can  be  included  on  one  ATR,  so  up  to  ten 
serial  numbers  may  be  included  in  this  record.  Unfortunately,  in  one  regard,  variable 
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TABLE  5 

SAMS  FILE  GROUPS 

DB  File  ( . dbf ) 

Index  File  ( 

ndx) 

Format  Files  (  .  fmt) 

AMREQUIS 

AMRSERUP 
AMRSERDW 
AMRREQDD 

ADDREQUI 

AMMODATA 

AMANALC 
AMACOGSY 

AMAMCONC 
AMANIIN 

ADDAMMO 

AMMODATA.  dbt 
(memo  field) 

AMTRANS 

AMTSERUP 
AMTSERDW 
AMTTRCD 
AMTNIIN 

ADDTRANS 

AMINVEN 

AMINIIN 

AMICONCD 

AMIACCL 

ADDINVEN 

AMTURNIN 

AMUSERUP 
AMUSERDW 
AMUNIIN 

ADDTURN 

AMALLOW 

AMWNALC 
AMWALTP 

ADDALLOW 

AMNARACT 

AMNNIIM 

AMNSERUP 

AMNSERDW 

ADDNARAC 

AMNARSER 

AMENARSR 

ADDNARSE 

AMSTDATA 

none 

ADD SD AT A 

AMDADDR 

AMDUIC 
AMDACTNM 

ADDADDRE 

DBSYSTEM. db 

none 

none 

CONTFILE 

CONTNAME 

none 

DATAELEM 

DATANAME 

DATAELSR 

DATAELDIC 

DICFILES 

DICFILTP 

none 

PROGFILE 

PROGNAME 

none 

i 

record  lengths  are  not  defined  in  a  relational  data  base  system,  so  some  storage  space 
will  be  wasted  because  most  transactions  do  not  involve  items  with  serial  numbers. 
Only  rarely  would  a  transaction  involve  more  than  ten  serial  numbers.  In  this  case,  a 
second  transaction  report  could  be  prepared. 
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The  ATR  Julian  Date  (ATRJULDAT)  is  the  three-digit  Julian  day  of  the  year 
that  the  ATR  is  prepared  and  appears  in  the  header  line  of  the  message.  It  will  not 
necessarily  be  the  same  as  the  message  DTG. 

The  beginning  and  ending  balance  must  be  maintained  in  the  Transaction  file 
because  the  Inventory  file  is  dynamic  in  nature  having  the  "instantaneous"  stock  levels. 
Thus  the  Transaction  file  is  the  historical  record  of  stock  levels. 

Quantity  seems  an  obvious  data  element  in  the  ATR,  however  if  the 
transaction  is  a  receipt  or  issue,  the  document  number  of  the  associated  receipt  or  turn- 
in  document  is  also  included.  This  case  would  violate  the  Third  normal  form  because 
quantity  is  part  of  these  documents.  However,  Quantity  must  be  included  because 
expenditure  transactions  have  no  corresponding  document. 

The  User  Source  Identification  Code  (IDCODE)  is  a  similar  situation.  For 
receipts  and  issues  the  IDCODE  would  be  the  "ship  to"  or  "received  from"  on  the 
shipping  document,  however  in  other  cases  it  can  take  on  other  values. Thus  it  must  be 
included  as  part  of  the  record. 

Finally,  any  narrative  message  (ATRREMARKS)  must  be  saved  and  this  is 
naturally  the  only  place  to  do  that. 

The  preceeding  description  of  the  Transaction  file  and  it's  structure  may  have 
seemed  rather  tedious,  however  the  reader  should  take  heart  that  commonalities  in  the 
other  files  will  not  be  repeated. 

2.   Requisition  File 

Serial  number  and  Julian  date  uniquely  identify  the  requisition,  while  the  other 
two  components  of  a  requisition  document  number  are  accessed  from  the  Static  Data 
file.  The  NUN  again  uniquely  identifies  the  item  that  is  being  ordered. 

The  requisitionee  and  supplemental  address  LTC  and  service  codes  are 
included  in  the  requisition  file.  Ninety  per  cent  of  the  time,  an  activity's  LTC  will 
determine  it's  service  designator  code,  however  if  that  activity  is  a  ship  and  it  changes 
fleets,  then  it's  service  designator  code  will  change.  The  supplemental  address  is 
normally  the  activity  at  which  the  material  will  be  received,  or  loadout  activity. 

Requisition  Status  (REQLTSSTAT)  serves  a  similar  purpose  to  that  in  the 
ATR  file  except  that  it  must  also  be  able  to  represent  partially  filled  and  cancelled 
requisitions. 

The  remaining  data  elements  are  multi-valued  codes  which  are  all  independent 
and  describe  the  circumstances  of  the  requisition,  urgency  of  need,  required  delivery 


56 


date.  etc..   See  Appendix  B,  the  Data  Element  Dictionary,  for  a  complete  description  of 
these  items.  This  file  also  satisfies  the  Boyce-Codd  Normal  Form. 

3.  Turn-in  File 

The  turn-in  file  may  seem  to  be  a  redundant  file  in  itself  because  it  will 
eventually  represent  a  turn-in  transaction  (issue  transaction).  However,  two 
considerations  help  to  clarify  the  need  for  ■he  file.  First,  a  turn-in  document  may  be 
prepared  well  ahead  of  the  actual  transaction  date  and  the  timing  of  the  inventory 
update  would  become  a  problem.  Certainly  the  inventory  should  not  be  updated  until 
the  physical  stock  levels  change.  Secondly,  a  turn-in  document  requires  three  or  four 
data  items  that  are  not  needed  on  a  transaction  report  and  thus  the  ATR  file  would  be 
made  needlessly  larger  just  to  accomadate  these  items. 

The  turn-m  file  record  must  be  able  to  uniquely  identify  an  item  of  inventory, 
just  as  the  ATR  file  must.  Therefore  the  same  five  data  elements:  NUN,  ACC,  CC,  lot 
number,  and  serial  number(s),  must  be  included  to  accomplish  this. 

The  ATR  serial  number  is  provided  to  link  the  record  to  the  transaction 
record  in  the  ATR  file.  This  data  would  be  automatically  appended  to  the  record  when 
the  transaction  document  was  prepared. 

Finally,  a  link  to  the  NAR  Action  file  is  necessary  if  the  turn-in  is  in  response 
to  a  NAR  message.  The  NAR  Serial  member  and  the  NAR  Year  accomplish  this. 

4.  Ammunition  Data 

This  file  contains  data  elements  that  provide  facts  about  specific  items  (types) 
of  ammunition.  The  unique  element  is  of  course  NUN.  This  file  essentially  replaces  the 
need  to  reference  two  or  three  large  publications  and  is  accessed  many  times  in  the 
application  programs.  The  Data  Element  Dictionary,  Appendix  B,  contains  complete 
explanations  of  these  independent  descriptors. 

One  "confusion  factor"  still  remains  however.  Although  NUN  reporting,  vice 
NALC  reporting,  is  logical  and  consistent  with  good  inventory  control,  NALC  is  still 
used  as  an  identifier  in  NAR  messages,  allowance  lists,  and  other  documents.  For 
years.  NALC  has  been  the  defacto  unique  identifier  of  ammunition  items,  and  until  all 
organizations  begin  using  NUN  as  such,  the  Ammunition  Data  file  will  serve  as  the 
NAR-to-NTIN  converter  in  application  programs. 

It  is  questionable  if  the  NALC  in  this  relation  could  be  considered  a  candidate 
key.  Many  of  the  data  elements  realistically  do  provide  a  fact  about  the  NALC,  a  non- 
key  field,  so  the  Third  Normal  Form  would  be  violated.  This  seems  unavoidable  in  this 
case  however. 
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5.  Inventory  File 

This  file  is  suprisingly  simple.  The  five  identifiers  o[  an  individual  item  are 
there  along  with  the  MDD  which  will  be  associated  with  serial  number  controlled 
items.  If  the  item  is  seriai  number  or  lot  serial  number  controlled  (MCC  "C"  or  MCC 
"E"),  the  quantity  for  the  record  will  be  one.  Items  that  are  only  lot  controlled  or  have 
no  MCC  will  have  a  quantity  that  reflects  all  the  items  in  the  lot.  This  relation  has 
such  a  large  key  (five  data  elements),  that  there  are  only  two  others  that  are  not 
included,  quantity  and  storage  location.  Boyce-Codd  Normal  Form  is  easy  to  attain  in 
this  case. 

6.  NAR  Action  File 

This  file  contains  reclassification  data  from  a  NAR  message  that  affects 
inventory  held  on  board.  Only  those  NARs  that  are  applicable  are  entered  here.  The 
NAR  Serial  File  records  all  NAR  messages  received  so  that  any  missed  messages  can 
be  noted. 

Naval  Ammunition  Reclassification  messages  identify  affected  ammunition  by 
NALC,  lot  number,  and  sometimes  serial  number.  Since  lot  numbers  are  not 
necessarily  unique,  and  a  NALC  may  contain  several  NTINs,  we  must  first  determine 
the  NTINs  associated  with  a  particular  NALC.  The  inventory  can  then  be  searched  for 
those  NTINs,  which  are  a  key  element  of  the  Inventory  file  as  well  as  an  index.  Upon 
locating  an  applicable  NUN,  the  lot  number  is  compared  with  that  contained  in  the 
NAR  message.  This  procedure  would  be  much  simplified  if  NAR  messages  used  NUN 
as  the  identifier. 

The  NAR  Action  File  also  contains  the  ATR  Serial  Number  which  took  the 
action  the  NAR  called  for.  This  would  be  automatically  appended  when  a 
reclassification  ATR  was  processed. 

Finally,  this  file  contains  a  character  field  to  record  the  reason  for 
reclassification,  which  is  normally  included  in  the  message  itself.  Also  a  field, 
TAGLABEL,  to  record  the  label  or  tag  that  must  be  attached  to  the  actual 
ammunition  to  explain  it's  status.  This  label  would  be  a  statement  like,  "For  Training 
Use  Only ", or  "For  Emergency  Combat  Use  Only". 
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7.  NAR  Serial  File 

This  file's  purpose  is  to  provide  a  convenient  location  to  record  all  the  NAR 
messages  received,  whether  applicable  or  not.  This  method  allows  the  NAR  Action  File 
to  be  much  smaller,  since  non-applicable  NARs  are  excluded.  Thus  we  minimize  the 
size  of  a  relation  with  nineteen  fields  by  creating  one  with  only  three.  This  file  is  in 
Fifth  Normal  Form,  which  means  that  it  is  in  BCNF  and  it  contains  no  transitive 
dependencies  'fourth),  and  it  can  not  be  subdivided  in  any  way. 

8.  Allouances  File 

This  file  contains  the  authorized  types  of  ammunition  and  quantities  that  a 
ship  may  earn-.  Allowance  Lists,  promulgated  by  the  Naval  Sea  Systems  Command 
(NAVSEA),  again  use  the  NALC  as  an  ammunition  identifier  [Ref.  3:  Chapter  7]. 
Remembering  that  the  various  NTINs  within  a  NALC  group  are  functionally 
equivalent,  it  is  clear  why  NAVSEA  publishes  the  lists  in  this  manner.  A  ship  may 
carry  any  NUN  item  within  the  NALC  group  to  satisfy  the  Allowance  List 
requirements. 

The  inclusion  oi  the  Activity  Classification  Code  (ACC)  in  the  Allowance  file 
allows  ammunition  for  other  end  uses  to  be  shown  in  this  file  rather  than  creating  a 
different  file  for  each  ACC  material  carried  onboard. 

Finally,  this  file  contains  a  computed  quantity,  USED  FY,  which  will  be 
automatically  updated  during  expenditure  ATR  processing  to  show  the  quantity  of 
ammunition,  which  has  a  training  allowance,  that  has  been  used  in  the  fiscal  year.  The 
system  manager  will  need  to  reinitialize  this  quantity  each  year.  Performing  the 
computation  at  this  time  and  storing  the  value  is  a  departure  from  strict  normalization, 
however  it  is  far  more  efficient  than  doing  all  of  the  calculations  just  prior  to  printing  a 
training  expenditure  report. 

9.  Address  File 

The  Address  file  contains  pertinent  data  about  other  supply  activities  and 
commands  with  which  a  ship  may  conduct  ammunition  business.  The  LTC  and  Activity 
Name  (ACTIVNA.ME)  are  both  candidate  keys,  however  LTC  is  less  easily  confused 
than  two  similar  names  and  it  is  also  only  five  characters.  This  makes  it  better  as  an 
index,  decreasing  search  time.  There  are  transitive  dependencies  in  this  file;  Activity 
Name  and  Location  can  determine  Service  Designator  Code,  however  Boyce-Codd 
Normal  Form  is  still  attained. 
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10.   Static  Data  File 

This  file  is  unique  in  that  it  only  contains  one  record,  namely  data  about  the 
ship  that  the  SAMS  is  installed  in.  It  furnishes  information  to  application  programs 
that  need  the  ship's  name,  hull  number,  etc.  to  print  documents  and  reports.  The  Fund 
Code  is  needed  on  requisitions  and  the  Monitoring  Activity  (MONTTACTIV)  is 
combined  with  the  Cognizance  Symbol  to  form  the  Distribution  Code,  used  on  several 
documents. 

The  remaining  database  files  are  for  system  documentation  and  will  not  affect 
the  operational  performance  of  the  system. 

B.       SAMS  STRUCTURE  CHARTS 

The  last  step  in  the  design  stage  is  to  determine  how  the  system  will  be 
partitioned  into  modules,  or  programs.  These  programs  will  operate  on  the  database 
relations,  via  the  DBMS,  and  interactively  with  the  user  to  perform  their  function. 
Unlike  a  Data  Flow  Diagram  (DFD),  the  structure  chart  presents  system  hierarchy, 
control,  and  communication.  Appendix  D  presents  the  SAMS  structure  charts. 

Structured  design  has  several  measures  with  which  to  gauge  the  quality  of  a 
system's  structure  chart.  The  first  is  coupling,  which  is  the  degree  of  independence 
between  modules,  and  the  objective  is  to  minimize  this.  The  second  is  cohesion,  which 
evaluates  how  closely  the  activities  within  a  module  relate  to  one  another.  A  module 
should  be  considered  a  "block,  box",  in  that  it  performs  it's  designated  function  with  the 
surrounding  modules  knowing  little  or  nothing  about  it's  internal  code.  [Ref.  15:  p. 
101,117] 

A  database  management  system  tends  to  make  structured  module  design  an 
easier  process  than  in  the  past.  The  problems  of  data  storage  are  removed  from  the 
application  programs  and  handled  by  the  DBMS,  thus  traditional  input,  output 
modules  are  not  necessary.  This  fact  allows  programs  to  flow  from  one  logical  process 
to  another  without  the  traditional  housekeeping  chores.  Previously,  structured  design 
techniques  responded  to  this  by  making  modules  very  small  with  single  cohesive 
functions.  A  DBMS  with  a  good  programming  language  can  produce  programs  that 
remain  understandable  and  cohesive  while  allowing  a  chain  of  logical  thoughts  to  be 
contained  in  one  program. 

The  SAMS  is  menu-drive  when  the  selections  are  unambiguous,  and  almost 
conversational  when  the  selections  require  a  more  detailed  knowledge.  Referring  to  the 
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TABLE  6 
SAMS  PHYSICAL  FILE  STRUCTURES 


Relation:  Transactions 
DBMS  Name:  AMTRANS. dbf 

Field   Field  Name   Type 


key  (ATRSERIAL) 
Width    Dec.    DEN 


*  ATRSERIAL 

2.  ATR STATUS 

3.  NUN 

4.  ACTCLCODE 

5.  CONDCCDE 

6.  TRANSCODE 
ATRJULDAT 

8.  L0TNUM3ER 

9./  OSSRNUM/ 

18.  9SERNUM 

19.  MDD 

20.  BEGBALANCE 

21.  END3ALANCE 
2  2 .  OAUNT I TY 

23.  DCCSVCCOD 

24.  DOCUIC 

25.  DOCJULDAT 
2  6.  DOCSERNUM 

27.  IDCCDS 

28.  MESSAGEDTG 

29.  ATRREMARKS 

Index  Files: 


Num 

Char(A 

Char 

Char( 

Char( 

Char( 

Num 

Char 

Char 

Char 

Char 

Char 

Char 

Num 

Char(A) 

Char 

Num 

Num 

Char 

Char 

Memo 

Field 
1 
1 

3 

6 


Relation: 
DBMS  Name: 


Requisitions 
AMREQUIS. dbf 


3 

1 

9 

1 

1 

1 

3 

16 

16 

16 

3 

5 

5 

5 

1 

5 

4 

4 

5 

14 

10 


0 


0 
0 


Name 

AMTSERUP 

AMTSERDW 

AMTNIIN 

AMTTRCD 


C089 

D046D 

E303 

C003E 

D219 

K002B 

C301 

D330 

D330 

C026 


K048 

A002 

K002C 

K002B 

I200/I602B 

C076 


increasing 
decreasing 


Field   Field  Name 


.ype 


key( SERIAL, JULIANDATE) 
Width   Dec     DEN 


1.  NUN 

2.  QUANTITY 

3.  *   SERIAL 

4.  *   JULIANDATE 

5.  PROJCODE 

6.  SZNDTOSERC 

7.  SSNDTOUIC 

8.  DOC I DENT IF 

9.  MEDIASTAT 

10.  DEMANDCCDE 

11.  SUPADDSERC 

12.  SUPADDUIC 

13.  SIGNALCODE 

14.  PRIORITYCD 

15.  REQDELDATE 

16.  ADVICECODE 

17.  REQUISSTAT 

Index  Files: 


Char 

9 

Char 

5 

Num 

4 

0 

Char 

4 

Char 

3 

Char 

1 

Char 

5 

Char 

3 

Char 

1 

Char( A) 

1 

Char 

1 

Char 

5 

Char( A) 

1 

Char 

2 

Char 

3 

Char 

2 

Char( A) 

X 

Field 

Name 

3 

AMRSERUP 

3 

AMRSERDW 

15 

AMRREQDD 

D046D 

K002C 

K002B 

K024 

K048 

A002 

K001 

K082 

K020 

K048 

A002 

K021 

K025 

K018 

K026 


( increasing 
( decreasing 
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TABLE  6 

SAMS  PHYSICAL  FILE  STRUCTURES  (CONT'D.) 

Relation:  Turn-in 

DBMS  N 

ame:  AMTURNI 

N.  dbf 

key( 

SERIAL 

, JUL I AND ATE) 

Field 

Field  Name 

Type 

Width 

Dec 

DEN 

X 

SERIAL 

Mum 

4 

0 

K002C 

2. 

NUN 

Char 

9 

D046D 

3. 

ACTCLCODE 

Char( A) 
Char( A) 

1 

E303 

4. 

CONDCODE 

1 

C003E 

5. 

LOTNUMBER 

Char 

16 

C301 

6./ 

CSERNUM/ 

Char 

16 

D330 

15. 

9SERNUM 

Char 

16 

D330 

16. 

OUANTITY 

Num 

5 

0 

17. 

* 

JUL I AND ATE 

Char 

4 

K002B 

18. 

SHIPTOUIC 

Char 

5 

A002 

19. 

ATRSERIAL 

Num 

3 

0 

C089 

20. 

NARSERIAL 

Num 

3 

0 

C084 

21. 

PROJCODE 

Char 

3 

K02  4 

22. 

NARYEAR 

Num 

2 

0 

C083 

23. 

TURN INST AT 

Char(  A) 

1 

Index  Files: 

Field 

Name 

1 

AMUSERUP 

( increasing) 
( decreasing) 

1 

AMUSERDW 

2 

AMUNIIN 

Relation:  Ammunition  Data 

DBMS  N 

ame:  AMMODATA.  dbf 

key( 

Field 

Field  Name 

Type 

Width 

Dec 

DEN 

1. 

7C 

NUN 

Char 

9 

D046D 

2. 

NALC 

Char 

4 

C003C 

3. 

FEDSUPCLAS 

Num 

4 

0 

C042 

4. 

SHORTTITLE 

Char 

20 

5. 

COGSYMBOL 

Char 

2 

C003 

6. 

UNITOFISSU 

Char 

2 

C005 

7. 

UNITPRICE 

Num 

10 

0 

B053 

8. 

MATLCONCOD 

Char 

1 

C003A 

9. 

DOTCLASCOD 

Char 

2 

P255 

10. 

HAZARDMTCD 

Char 

4 

D196 

11. 

NETEXPWT 

Char 

10 

C304E 

12. 

SECRISKCOD 

Char 

1 

C017 

13. 

LONGTITLE 

Memo 

10 

14. 

TMDC 

Char( A) 

1 

C010 

15. 

FRECLASNM 

Char 

32 

Index  Files: 

Field 

Name 

1 

AMANIIN 

2 

AMANALC 

5 

AMACOGSY 

8 

AMAMCONC 
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TABLE  6 

SAMS  PHYSICAL  FILE  STRUCTURES  (CONT'D.) 

Re  I 

ation:  Inventor 

y       key (  NUN,  LOTNUMB 

ER. 

DBMS  N 

ame:  AMINVEN 

. dbf    SERNUMBER, CONDCODE; ACTCLCODE) 

Fi  e 

Id 

Field  Name 

Type 

Width   Dec 

DEN 

X 

NUN 

Char 

9 

D046D 

2. 

X 

LCTNUMBER 

Char 

16 

C301 

3. 

X 

SERNUMBER 

Char 

16 

D330 

4. 

MDD 

Char 

3 

C026 

5. 

X 

CCNDCODE 

Char(A) 

Char( A) 

i 

C003E 

6. 

X 

ACTCLCODE 

1 

E303 

7. 

QUANTITY 

Num 

5 

8. 

STORAGE LC 

Char 

30 

Index  Files: 

Field 

Name 

1 

AMINIIM 

6 

AMICONCD 

7 

AMIACCL 

Rel 

ation:  NAR  Action 

DBMS  N 

ame:  AMNARACT. dbf    key( NARSERIAL , NARYEAR ) 

Fie 

Id 

Field  Name 

Type 

Width   Dec 

DEN 

] 

NUN 

Char 

9 

D046D 

2. 

LCTNUMBER 

Char 

16 

C301 

3./ 

OSERNUM 

Char 

16 

D330 

12. 

9SERNUM 

Char 

16 

D330 

13. 

* 

NARSERIAL 

Num 

3       0 

C084 

14. 

X 

NARYEAR 

Num 

2       0 

C083 

15. 

CLDCONDCD 

Char( A] 

1   1 

C003E 

16. 

NEWCONDCD 

Char(  a; 

1   1 

C003E 

17. 

ATRSERIAL 

Num 

3       0 

C089 

13. 

NARREMARKS 

Char 

40 

19. 

TAGLA3EL 

Char 

30 

Index  Files: 

Field 

Name 

1 

AMNNI IN 

4 

AMNSERUP  ( 
AMNSERDW  ( 

increasing) 
decreasing) 

4 

Rel 

ation:  NAR  Serial 

D3M 

S  N 

ame:  AMNARSER. dbf 

key( NARSERIAL 

, NARYEAR ) 

Fie 

Id 

Field  Name 

Type 

Width   Dec 

DEN 

1. 

X 

NARSERIAL 

Num 

3       0 

C084 

2. 

X 

NARYEAR 

Num 

2       0 

C083 

3. 

NARDTG 

Char 

14 

C078 

Index  Files: 

Field 

Name 

1 

AMENARSR 
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TABLE  6 
SAMS  PHYSICAL  FILE  STRUCTURES  (CONT'D.) 


Relation: 
DBMS  Name: 


Allowances 
AMALLOW. dbf 


Field   Field  Name   Type 


key( NALC , ACTCLCODE ) 
Width    Dec     DEN 


1 

2. 
3. 

4. 
5. 

*  NALC 

*  ACTCLCODE 
QUANTITY 

TRNGALLOW 
USED/FY 

Char 
Char( A) 

Num 
Num 
Num 

4 
1 
5 
5 
5 

C003C 
E303 

0 

0 

0 

Index  Files: 

Field 
1 
2 

Name 

AMWNALC 

AMWALTP 

Relation:  Address 
DBMS  Name:  AMDADDR 

dbf 

key(UIC) 

Fie 

Id   Field  Name 

Type 

Width   Dec    DEN 

1. 
2. 

3. 
4. 
5. 

6. 

SERVCODE 
*   UIC 

ACTIVNAME 
LOCATION 
HULLNUMBER 
ROUT I DENT 

Char 
Char 
Char 
Char 
Char 
Char 

1             K048 

5             A002 

30            D192 

30            A045 

8 

3             A001 

Index  Files: 

Field 
2 

3 

Name 

AMDUIC 
AMDACTNM 

Relation:  Static  Data 
DBMS  Name:  AMSTDATA. dbf 

key(UIC) 

Fie 

id   Field  Name 

Type 

Width   Dec     DEN 

1. 
2. 
3. 
4. 
5. 

6- 

UNITNAME 
HULLNUMBER 
SERVCODE 
*   UIC 

FUNDCODE 
MONITACTIV 

Char 
Char 
Char 
Char 
Char 
Char 

45 

8 

1 

5 

2 

1 

D192 

K048 
A002 
K022 

Index  Files:   none 

1 
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TABLE  6 
SAMS  PHYSICAL  FILE  STRUCTURES  (CONT'D.) 


Relation:  Data  Elements 
DBMS  Name:  DATAELEM. dbf 

Field   Field  Name   Type 


key( NAME, SOURCE_FIL) 


Width 


r> 


ec 


DEN 


NAME 

Char 

10 

PICTURE 

Char 

6 

SOURCE  FIL 

Char 

50 

DESCRIFIO 

Char 

2  40 

DEN 

Char 

6 

LONGTITLE 

Char 

55 

CODES 

Memo 

10 

REFERENCE 

Char 

70 

ex  Files: 

Fie 

Id 

Name 

DATANAME 

3 

DATAELSR 

Relation: 
D3MS  Name: 


Contains  File 
CONTFILE.  dbf 


Field   Field  Name   Type 


key(NAMEOFPROG) 
Width   Dec     DEN 


i.   *   NAMEOFPROG   Char 
2.      CONTAINS     Char 

Index  Files: 


8 
50 


Field 
1 


Relation: 
DBMS  Name; 


Systems  File 
DICFILES. dbf 


Field   Field  Name   Type 


Name 
CONTNAME 


key( FILE_NAME) 
Width    Dec     DEN 


1.  *   FILE  NAME 

2.  FILE  TYPE 
5.      DESCSIPIO 

Index  Files: 


Char 
Char 
Char 


8 

d 

40 


Field 
2 


Name 
DICFILT? 


Relation:  System  Programs 
DBMS  Name:  PROGFILE. dbf 

Field   Field  Name   Type 


key(PROG_NAME) 
Width     Dec     DEN 


1.  *   PROG  NAME 

2.  CALLS" 

3.  PURPOSE 

4.  CALLED_BY. 

Index  Files: 


Char 
Char 
Char 
Char 


8 

ICO 

70 

80 


Field 
1 


Name 
PROGNAME 
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TABLE  6 
SAMS  PHYSICAL  FILE  STRUCTURES  (CONT'D.) 


DBMS    Name:     DBSYSTEM. db         key( GROUP    NAME, LOG    IN   NAM, 

PASSWORD)      "   ~ 


Relation:  User's  File 
DBMS  Name:  DBSYSTEM. d 

Field   Field  Name   Type     Width   Dec    DEN 

*   GROUP  NAME   Char       8 

2.  *   LOG  Ifl  NAM   Char       8 

3.  *   PASSWORD     Char       16 

4.  ACCOUNT  NM   Char       24 

5.  ACCESS_L"VL   Num        1       0 

NOTE:  This  is  a  special  relation  established  within 
the  PROTECT  program  of  the  dBase  1 11+  and  is 
encrvpted.  Ix.   may  only  be  modified  by  the  DB 
Administrator.  Fields  one,  two,  and  three  are  man- 
datory. The  access  level  may  be  one  through 
eight,  with  one  giving  the  most  priveledges. 


major  subsystem  diagram  in  Appendix  D,  we  see  that  the  main  menu  allows  the  user  to 
select  one  of  nine  options,  each  is  completely  independent  of  the  other.  This  is  an 
example  of  low  coupling  which  is  desireable.  Each  subsystem  then  presents  another 
menu  which  will  determine  what  the  user  desires  to  do.  The  SAMS  generally  has  four 
levels  of  hierarchy  in  it's  application  programs: 

1 .  The  main  menu 

2.  The  subsystem  menu 

3.  The  application  desired 

4.  Utility  programs  (infrequent) 

Examples  o{~  utility  programs  can  be  seen  in  the  Requisition  Management  subsystem 
under  the  Print  Requisition  application  module. 

In  general,  very  few  parameters  are  passed  in  the  system.  Facilitating  this  is  the 
fact  that  in  dBase  III  Plus  ,  a  called  program  can  manipulate  variables  in  the  caller 
program  without  parameters  being  passed.  This  can  be  convenient,  but  it  can  also  have 
dangerous  implications.  The  programmer  must  ensure  that  the  called  program  does  not 
inadvertently  alter  variables  in  the  main  program  that  were  not  intended.  Of  course,  by 
not  using  parameters,  a  programmer  limits  the  usefulness  of  his  programs  by  making 
them  dependent  on  a  particular  application.  For  further  background  on  parameter 
passing  and  implicit  and  explicit  inheritance  the  reader  is  referred  to  MacLennon 
[Ref.  24]. 
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Structure  charts  provide  the  programmer  with  a  framework  for  the 
implementation  of  the  various  subsystems  and  individual  modules,  while  the  Data  Flow 
Diagrams  provide  a  guide  to  the  logical  processes  of  the  subsystems.  Neither  graphical 
representation  should  be  regarded  as  "cast  in  concrete"  however,  the  physical 
implementation  may  suggest  modifications. 
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V.  IMPLEMENTATION 

A.       IMPLEMENTATION  PROGRESS  TO  DATE 

Early  in  the  developement  of  the  SAMS,  it  was  obvious  that  complete 
implementation  and  field  testing  would  be  quite  impossible  in  the  available  research 
time.  Therefore  the  author  selected  the  portions  of  the  implementation  that  would  be 
the  most  beneficial  to  anyone  continuing  the  effort,  and  provide  a  framework  for  that 
implementation. 

The  design  stage  identified  all  of  the  programs  necessary  for  the  SAMS.  They  are 
listed  in  the  PROG  FILE  database  and  may  be  printed  with  their  associated  data  by 
running  PROGFILE.prg.  Appendix  C  contains  this  listing.  Approximately  one  quarter 
of  the  systems  programs  have  been  implemented. 

The  Requisition  Management  subsystem  was  fully  implemented  because  it's 
programs  demonstrate  a  myriad  of  programming  techniques  to  accomplish  their  tasks. 
There  are  modules  to  review  databases,  edit/delete,  create  documents,  print  documents, 
backup  files,  and  various  forms  of  interactive  programming  are  demonstrated.  Most  of 
the  other  SAMS  subsystems  use  many  of  these  processes,  so  a  close  review  of  the 
Requisition  Management  programs  can  significantly  decrease  the  learning  curve  for 
future  programmers.  Completed  program  listings  are  contained  in  Appendix   E. 

In  addition,  the  database,  index,  and  format  files  necessary  to  operate  the 
Requisition  Management  subsystem  were  created  and  loaded  with  sample  data. 
Testing  was  performed  throughout  the  implementation  of  these  modules  to  show 
correct  operation,  although  not  exhaustive  or  as  a  dedicated  separate  evolution. 
System  testing  is  obviously  a  critical  phase  of  the  developement  process  not  to  be 
slighted.  Module  independence  will  greatly  facilitate  testing  and  make  rapid  debugging 
possible. 

Many  of  the  system  documentation  modules  were  also  completed  during  the 
analysis  and  design  stages  and  should  greatly  assist  future  programmers.  These  include 
the  Data  Element  Dictionary,  structure  charts,  program  files,  files  directory,  and  cross 
reference  between  programs  and  relations. 
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B.       CODING  STYLE 

Without  repeating  at  length  the  ideas  that  have  been  presented  throughout  this 
paper  concerning  the  interactive  style  of  the  SAMS,  it  might  be  worthwhile  to  bring 
together  in  one  spot  the  essential  points. 

First.  SAMS  must  be  easy  tc  use.  Although  larger  ships  may  be  able  to  dedicate 
a  single  person  tc  the  responsibility  for  system  operation  as  a  primary  duty,  this  will 
normally  not  be  the  case.  Therefore  the  slant  should  be  toward  more  information, 
rather  than  less,  in  the  interactive  process.  This  assumes  the  operator  will  not  be  so 
niliar  with  the  system  that  the  extra  information  will  be  annoying.  The  Requisition 
Management  option  presents  the  user  with  most  of  the  information  that  could  be 
gleaned  from  several  publications.  The  difference  is  that  the  publications  contain  a 
)le  range  of  logistics  information,  and  the  SAMS  will  present  pertinent  information 
chat  flee:  users  need  and  no  more.  Therefore,  the  key  phrase  is  "complete,  selective 
information". 

The  system  administrator,  or  manager,  must  be  knowledgeable  of  the  instructions 
and  publications  that  explain  the  present  system,  and  the  operators  must  have  a 
working  knowledge.  The  manager  should  understand  the  basics  of  dBase  III  Plus,  not 
to  the  degree  of  being  able  to  program,  but  enough  to  be  able  manipulate  relations 
should  a  problem  arise.  Moreover,  he  should  understand  the  implications  of  his  ability 
to  alter  those  relations. 

Finally,  code  documentation  should  primarily  be  contained  within  the  listing 
itself.  Placing  it  here  will  increase  the  chances  of  it  being  useful  to  a  future  maintenance 
programmer,  and  it  will  be  easier  to  maintain  of  its  own  accord.  Some  authors  feel  that 
source  code  comments  are  perhaps  the  easiest  form  of  documentation  to  maintain, 
[Ref.  17:  p.  251  and  341],  and  this  author  would  tend  to  agree. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  Shipboard  Ammunition  Management  System  presented  in  this  thesis  is  one 
viable  alternative  to  the  present  system.  It  automates  much  of  the  manual  record 
keeping,  can  prepare  useful  management  reports,  and  produce  external  documents 
compatible  with  the  supply  system's  ADP  equipment. 

There  are  several  factors  that  make  a  stand  alone  system  difficult  to  design.  First, 
it  must  be  compatible  with  different  processing  systems.  It  must  automate  manual 
procedures  on  one  hand  and  on  the  other  hand  it  must  produce  documents  that  are 
compatible  with  machine  readable  capabilities  of  the  shore  establishment.  This 
dichotomy  has  in  part  been  a  reason  why  the  system  has  been  getting  more  difficult  for 
the  "customer",  the  fleet  user,  to  maintain.  Machine  readable  ATR's  may  eliminate  key- 
punching errors  at  the  SPCC  level,  however  they  are  incomprehensible  at  the  user  level 
except  to  the  preparer.  Every  message  that  leaves  a  ship  should  be  checked  for 
accuracy  by  at  least  two  people  prior  to  the  commanding  officer  signing  his  permission 
to  transmit,  and  this  could  run  into  considerable  manhours  if  everyone  must  dig 
through  publications  to  look  up  "funny  codes  and  formats". 

Thus,  a  second  alternative  to  solve  the  problem  is  to  extend  automation 
capabilities  to  all  ships  from  the  shore  based  ammunition  management  systems.  A 
unified  system,  with  one  set  of  rules,  would  definitely  be  superior  to  a  fragmented 
system.  The  professional  managers  of  ammunition  ashore  would  then  be  able  to  extend 
their  expertise  to  the  fleet,  in  order  to  allow  the  professional  users  of  the  ammunition 
to  practice  that  more,  and  management  less. 

A  second  problem,  as  this  author  perceives  it,  is  the  overlapping  of  directives 
between  the  supply  system  and  the  fleet  logistics  agents.  The  fleet  user  should  deal  with 
one  set  of  rules,  perferably  one  definitive  reference.  For  example,  in  the  Pacific  Fleet,  a 
submarine  weapons  officer  has  three  levels  of  guidance  concerning  conventional 
ammunition  management  [Refs.  3,4]  and  operational  force  commander  instructions. 
Now.  there  may  be  good  reasons  for  modifications  depending  on  the  theatre  of 
operations  or  weapon  type,  but  the  users  guidance  should  come  from  one  place,  to 
minimize  confusion.  Consistently  following  this  policy  would  probably  reduce  by  one 
third  the  number  of  publications  that  a  typical  ship  is  required  to  carry,  in  weight  if  not 
in  number. 
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The  Shipboard  Non-tactical  ADP  System  (SNAP)  is  currently  being  installed  on 
Navy  ships  in  increasing  numbers  and  is  designed  to'  handle  many  supply,  maintenance, 
and  administrative  functions  previously  done  manually.  This  could  provide  an  excellent 
vehicle  to  automate  the  ammunition  management  function.  This  thesis  and  others 
could  provide  functional,  if  not  design  descriptions  of  such  a  subsystem  to  SNAP. 

Finally,  if  the  preceeding  alternatives  can  not  be  economically  or  politically 
justified,  then  a  stand  alone  system,  the  SAMS,  should  be  pursued.  The  author 
estimates  two  to  four  months  of  programming  would  complete  the  SAMS  application 
programs,  then  a  pilot  ship  should  be  selected  for  the  initial  installation.  The  SAMS 
should  run  in  parallel  with  the  existing  manual  system  to  gather  user  experience, 
document  "bugs",  and  adjust  user  interface.  This  phase  would  be  an  extremely 
interesting  follow-on  thesis  in  itself.  Ultimately  there  must  be  a  program  office  for  the 
SAMS,  logically  as  part  of  CALMS  at  SPCC,  to  provide  guidance  and  installation 
assistance  to  the  fleet. 

Therefore,  the  problems  of  conventional  ammunition  management  can  be 
handled  in  one  of  three  ways: 

1.  An  automated  system  within  the  CAIMS  from  SPCC  down  to  all  shipboard 
users. 

2.  Inclusion  of  ammunition  management  in  SNAP. 

3.  Stand  alone  ammunition  management  -  SAMS 

The  goal  in  selecting  any  one  of  the  three  is  to  improve  and  unify  the  system,  and  to 
reduce  the  administrative  burden  on  shipboard  personnel.  The  status  quo  will  not  be 
suitable  in  the  long  term  if  we  desire  an  increase  in  fleet  readiness. 
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APPENDIX  A 
DATA  FLOW  DIAGRAMS 
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APPENDIX  B 
DATA  ELEMENT  DICTIONARY 

DEN:  D330 
NAME:  OSERNUM 

LONG  T^TLi:   Component  Serial  Number  (First) 

PIC:  X(16) 

2i.SC:  The  first  instance  of  a  serialized  component  in  a  transaction 
report,  turn-in  document,  or  a  NAR  action  file  entry.  The 
definition  of  component  serial  number  is  the  same  data 
element  SERNUMBER. 

USED  IN :  AKNARACT , AMTRANS , AMTURNIN 

REFS  : 

DEN:  D330 

NAME:  ISERNUM 

LONG  TITLE:  Component  Serial  Number  (Second) 

PIC:  X(16) 

DESC:  Same  as  OSERNUM,  except  second  instance. 

USED  IN:  AMNARACT, AMTRANS, AMTURNIN 

REFS: 

DEN:  D330 

NAME:  2SERNUM 

LONG  TITLE:  Component  Serial  Number  (Third) 

?IC:  X(15) 

DESC:  Same  as  OSERNUM,  exceDt  third  instance. 

USED  IN:  AMNARACT, AMTRANS , AMTURNIN 

REFS: 

DEN:  D330 

NAME:  3SERNUM 

LONG  TITLE:  Component  Serial  Number  (Fourth) 

PIC:  X(i6) 

DESC:  Same  as  OSERNUM,  except  fourth  instance. 
USED  IN:  AMNARACT, AMTRANS, AMTURNIN 

?.ZFS: 

DEN:  D330 

NAME:  4SERNUM 

LONG  TITLE:  Component  Serial  Number  (Fifth) 

PIC:  X(16) 

DESC:  Same  as  OSERNUM,  except  fifth  instance. 

USED  IN:  AMNARACT , AMTRANS , AMTURNIN 

REFS  : 

TEN:  D330 

NAME:  55ERNUM 

LONG  TITLE:  Component  Serial  Number  (sixth) 

PIC:  X(16) 

IESC:  Same  as  OSERNUM,  except  sixth  instance. 

USED  IN:  AMNARACT, AMTRANS, AMTURNIN 

REFS: 

DEN:  D330 

NAME:  6SERNUM 

LONG  TITLE:  Component  Serial  Number  (Seventh) 

PIC:  X(16) 

DESC:  Same  as  OSERNUM,  except  seventh  instance. 

USED  IN:  AMNARACT, AMTRANS, AMTURNIN 

REFS: 
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DEM:  D330 

NAME:  7SERNUM 

LONG  TITLE:  Component  Serial  Number  (Eight) 

PIC:  X(16) 

DESC:  Same  as  OSERNUM,  except  eight  instance. 

USED  IN:  AMNARACT, AMTRANS, AMTURNIN 

REFS: 

DEM:  D330 

NAME:  3SERMUM 

LONG  TITLE:  Component  Serial  Number  (ninth) 

PIC:  X(16) 

DESC:  Same  as  OSERNUM,  except  ninth  instance. 

USED  IN:  AMNARACT, AMTRANS, AMTURNIN 

REFS: 

DEN:  D330 

NAME:  9SERNUM 

LONG  TITLE:  Component  Serial  Number  (tenth) 

PIC:  >I(16) 

DESC:  Same  as  OSERNUM,  except  tenth  instance. 

USED  IN :  AMNARACT , AMTRANS , AMTURNIN 
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DEN  : 

MANE:  ACCESSLEV 

LONG  TITLE:  Access  Level 

PIC:  9 

DESC-  Determines  the  level  of  user  access  or  priveledges  within 
the  SAMS  system;  ranging  from  one  to  eight  with  one  the 
most  powerful  and  eight  the  lowest.  Used  to  regulate 
access  to  various  menu  options  from  the  main  menu. 

USED  IN:  DBSYSTEM 

REFS: 

DEN  : 

NAME:  ACCOUNTNAM 

LONG  TITLE:  Account  Name 

PIC:  X(24) 

DESC:  An  optional  24  character  field  in  the  users  file  that 

may  be  used  by  the  SAMS  manager  to  record  the  users 

full  name  or  other  information. 
USED  IN:  DBSYSTEM 
REFS: 

DEN:  E303 

NAME:  ACTCLCODE 

LONG  TITLE:  Activity  Classification  Code 

PIC:  A 

DESC:  Indicates  the  intended  use  of  ammunition  stocks  carried 
by  a  ship  or  activity. 

USED  IN:  AMINVEN, AMTURNIN, AMTRANS, AMALLCW 
REFS  : 

DEN:  D192 

NAME:  ACTIVNAME 

LONG  TITLE:  Activity  Long  Name 

PIC:  X(3C) 

DESC:  Name  of  the  activity  as  listed  in  the  Plain  Language 

Address  Directories  (PLAD)  if  available,  otherwise 

in  the  clear  name. 
USED  IN:  AMDADDR 
REFS: 

DEM:  KC26 
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NAME:  ADVICECODE 

LONG  TITLE:  Advice  Code 

PIC:  X(2) 

Cz.SC:  Advice  Codes  are  numeric/alphabetic  and  flow  from  the 

requisition  originators  to  initial  processing  points. 

The  purpose  is  to  provide  coded  instructions  to  supply 

sources  when  such  data  is  considered  essential  to 

the  supply  action. 
USED  IN:  AMREOUId 
REFS: 

TEN: 

NAME :  ATRJULDAT 

LONG  TITLE:  Ammunition  Transaction  Report  Julian  Date  (SAMS  LDE) 
PIC:  999 

DESC:  The  Julian  day  of  the  year  on  which  the  ATR  was  prepared. 

Consists  of  the  three  number  equivalent  of  the  day  of  the 

year. 
USED  IN:  AHTRANS 
REFS  : 

DEM : 

NAME:  ATRREMARKS 

LONG  TITLE:  Ammunition  Transaction  ReDort  Remarks  (SAMS  LDE) 

PIC:  X(150) 

CE5C:  Any  narrative  remarks  that  may  be  necessary  to  place  on 
an  ATR  to  clarify  a  transaction  or  provide  loadout  or 
RDD  information. 

USED  IN:  AMTRANS 

REFS: 

DEN:  C0S9 

NAME:  ATRSERIAL 

LONG  TITLE:  Ammunition  Transaction  Report  Serial  Number 

PIC:  9(3) 

CESC:  A  three  digit  number  assigned  to  the  sequence  of  an  ATR 

report.  The  numbers  run  from  001  to  999  and  then  repeat 

for  a  oarticular  unit. 
USED  IN :  AMTURNIN , AMTRANS , AMNARACT 
REFS: 

DEN: 

NAME:  ATRSTATUS 

LONG  TITLE:  Ammunition  Transaction  Report  Status  (SAMS  local  elem.) 

PIC:  A 

DESC:  A  one  character  alphabetic  code  that  indicates  the 

status  of  an  ATR  document. 
USED  IN:  AMTRANS 
REFS  : 

DEN: 

NAME :  5EGBALANCE 

LONG  TITLE:  Beginning  Balance  (SAMS  local  data  element) 

PIC:  X(5) 

DE5C:  The  inventory  balance  of  a  particular  ammunition  item 

Drior  to  a  transaction  occuring. 
USED  IN:  AMTRANS 
REFS: 

DEN: 

NAME:  CALLED_BY 

LONG  TITLE:  Program  called  by 

PIC j  X(80) 

CESC:  The  program  that  calls  the  program  in  question. 

USED  IN:  PROGrlLE 

REFS: 
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DEN: 

NAME :  CALLS 

LONG 'TITLE  :  Program  Calls 

PIC:  X(iOO) 

DESC:  The  name  of  the  program(s)  that  a  program  calls. 

USED  IN:  PROGFILE 

REFS  : 

DEN : 

MANE:  CODES 

LONG  TITLE:  Data  Element  Codes 

PIC:  memo 

DESC:  The  CAINS  codes  associated  with  a  particular  data 

element  stored  in  a  separate  memo  field. 
USED  IN:  DATAELEN 
REFS  : 

DEN:  C003 

NAME:  COGSYNBOL 

LONG  TITLE:  Cognizance  Symbol 

PIC:  X(2) 

DESC:  The  Cognizance  Symbol  is  a  two  position  code  prefix 
to  National  Stock  Number  to  identify  and  designate 
the  Inventory  Control  Point,  office,  or  agency  which 
exercises  Supply  Management  of  the  item. 

USED  IN:  AMMODATA 

REFS: 

DEN:  C003E 

NAME:  CONDCODE 

LONG  TITLE:  Condition  Code 

PIC:  A 

DESC:  A  single  alphabetic  character  which  classifies 

material  in  terms  of  readiness  for  issue  and  use, 
or  to  identify  action  underway  to  change  the 
status  of  the  material. 

USED  IN:  AMINVEN,AMTURNIN,AMTRANS 

REFS: 

DEN: 

NAME:  CONTAINS 

LONG  TITLE:  Relations  used  in  a  program 

PIC:  X(50) 

DESC:  The  relations  that  are  referenced  or  used  by  a 

particular  program  in  the  SAMS. 
USED  IN:  COMTFILE 
REFS: 

DEN:  K020 

NAME:  DEMANDCODE 

LONG  TITLE:  Demand  Code 

PIC:  X(A) 

DESC:  Demand  Code,  (R)recurring,  (N)non-recurring 

USED  IN:  AMREQUIS 

REFS:  (a),(b),(c) 

DEN:  G436 

NAME:  DEN 

LONG  TITLE:  Data  Element  Number 

FIC:  X(6) 

DESC:  A  six-digit  alphanumeric  data  field  used  to 

identify  data  elements  resident  in  the  system  data 
base.  Obtained  from  NAVSUP  Pub  508.  Supply 
Management  Program  Standard  Data  Element  Dictionary 
and  keyword  index. 

USED  IN:  DATAELEN 
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REFS: 

DEN: 

NAME:  DESCRIPTIO 

LONG  TITLE:  Description 

PIC:  X(40) 

DE5C:  The  meaning  of  a  data  element  or  the  content  of  a 

file . 
USED  IN:  DICFILES,  DATAELEM 
RTFS: 


:z:r: 

MAHE 
LONG 

PIC: 
DESC 


USED 
REr  5 


K001 
:  DOCIDENTIF 

TITLE:  Document  Identifier 
XXX 

:  -he  document  identifier  code  provides  identification 
of  each  document  type  (i.e.  requisition, cancellation, 
foilcw-uD, transfer, etc. ) 
IN:  AMREQUiS 
:  (A),(B),(c),(d) 


DEN: 

:;a::z 

LONG 
PIC  : 

DE5C 


USED 
REFS 


K002B 
DOCJULDAT 

TITLE:  Document  Julian  Date 

9(4) 
Identifies  the  date  that  the  document  or  requisition 
was  established.  Consists  of  the  units  digit  of  the 
calender  year  and  numeric  values  equivalent  to  the 
day  of  the  year  (Julian  date). 

IN:  AMTRANS 


DEN: 
MAKE 
LONG 
PIC: 
DESC 


USED 
REFS 


K002C 
:  DOCSERNUM 

TITLE:  Document  Serial  Number 

9(4) 

:  T.ie  portion  of  the  Document  Number  which  applies  to 
the  serial  number  of  the  document.  Used  in  the 
Transaction  File  it  can  indicate  the  serial  number 
of  either  a  requisition  or  a  Turn-in  document, 
differentiated  Py  the  transaction  code. 

IN:  AMTRANS 


DEN:  K048 

NAME:  DOCSVCCOD 

LONG  TITLE:  Document  Service  Code  (SANS  local  data  element) 

PIC:  A 

DESC:  The  service  designator  portion  of  the  Document 

Number  which  is  required  on  an  issue  or  receipt  ATR. 

Obtained  from  the  requisition  or  turn_in  file. 
USED  IN:  AMTRANS 
REFS: 

DEN:  A002 

NAME:  DOCUIC 

LONG  TITLE:  Document  Unit-Identification-Code   (SAMS  LDE) 

PIC:  X(5) 

DESC:  The  UIC  portion  of  a  Document  Number  that  is  required 

on  an  issue  or  receipt  ATR.  Obtained  from  the  requisition 

or  turn-in  file  as  appropriate. 
USED  IN:  AMTRANS 
REFS  : 

DEM:  P255 

NAME :  DOTCLASCOD 
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LONG  TITLE:  Department  of  Transportation  Class  Code 

PIC:  XX 

DESC:  A  code  assigned  to  the  classification  assigned  by  the 
Department  of  Transportation  to  indicate  the  type  of 
hazard  involved  when  shipping  the  ammunition  item. 

USED  IN:  AMMODATA 

REFS: 

DEN: 

NAME:  ENDBALANCE 

LONG  TITLE:  Ending  Balance   (SAMS  local  data  element) 

PIC:  X(5) 

DESC:  The  inventory  balance  of  a  particular  ammunition 

item  after  a  transaction  has  occured. 
USED  IN:  AUTRANS 
RnFS  : 

DEM:  C042 

NAME:  FEDSUPCLAS 

LONG  TITLE:  Federal  Supply  Classification 

PIC:  9(4) 

DZSC:  A  code  assigned  by  the  governmaent  to  designate 

various  groups  of  common  use,  commercial  type  items. 
USED  IN:  AMMODATA 
REFS: 

DEN: 

NAME:  FILE_NAME 
LONG  TITLE:  File  Name 
PIC:  X(S) 

DESC:  Name  of  the  file  and  may  be  a  database  file(.dbf), 
or  an  index  file(.ndx),  or  a  format  file(.fmt). 


USED 

IN:  DICFILES 

REFS: 

DEN: 

NAME  : 

:  FILE  TYPE 

LONG 

TITLE:  File  Type 

PIC: 

X(4) 

DESC: 

:  Type  of  file:  d 
format ( . fmt) 

USED 

IN:  DICFILES 

REFS: 

database ( .dbf) ,  index  file(.ndx), 


DEN: 

NAME:  FRECLASNM 

LONG  TITLE:  Freight  Classification  Nomenclature 

PIC:  X(32) 

DESC:  The  proper  shipping  name  prescribed  for  the  material 
as  required  by  Title  49  CFR,  Part  172.101,  and  the 
DOT  hazard  class(spelled  out).  Given  under  the  GBL 
Description  column  in  NAVSEA  OP2165, 
usually  2-5  word  desc.  and  Class  "  "  Explosive. 

USED  IN:  AMMODATA 

REFS  : 

DEN:  K022 

NAME:  FUNDCODE 

LONG  TITLE:  Fund  Code 

PIC:  XX 

DESC:  A  two  character  code  which  is  used  to  cite  accounting 

data  on  Navy  requisitions.  Fleet  units  use  fund  code  Y6 

and  shore  units  use  fund  code  26. 
USED  IN:  AMSTDATA 
REFS: 
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DEN: 

NAME:  GROUP_NAME 

LONG  TITLE:  Group  Name 

PIC:  X(8) 

DESC:  An  eight  character  word  that  must  be  entered  by  the 
user  of  the  SANS  in  order  for  the  protection 
functions  of  the  system  to  allow  him  access 
to  the  system. 

USED  IN:  DBSYSTEM 

REFS  : 

DEN:  D196 

NAME:  HAZARDMTCD 

LONG  TITLE:  Coast  Gaurd  Hazardous  Material  Code 

PIC:  X(4) 

DESC:  Classification  of  military  explosives  and  hazardous 

munitions  as  determined  bv  the  US  Coast  Gaurd  and 

set  forth  in  NAVSEA  OP  2I&5  Vol.2.  Ammunition  aboard 

ail  classes  of  ships  must  be  loaded 

in  accordance  with  the  guidance  contained  in  CG108. 
USED  IN:  AKMODATA 
REFS  : 

DEN: 

NAME:  HULLNUNEER 

LONG  TITLE:  Hull  Number  of  vessel  (SAMS  local  data  element) 

PIC:  X(3) 

DESC:  Hull  Number  of  shio;  SSN635 ,FFI096 ,etc . 

USED  IN:  AMDADDR,AMSTDATA 

REFS: 

DEN: 

NAME:  ID CODE 

LONG  TITLE :  I.D.  Code    (SAMS  local  data  element) 

PIC:  X(5) 

DESC:  The  UIC  of  the  issuing  unit  or  a  code  indicating  the 
ACC  or  other  source  of  the  material  involved  in  the 
transaction;  or,  the  UIC  of  the  receiving  unit  or  a 
code  indicating  the  ACC  changed  to  or 
other  destination  of  the  material. 

USED  IN:  AMTRANS 

REFS  : 

DEM:  K00  2B 

NAME:  JULIANDATE 

LONG  TITLE:  Document  Julian  Date 

PIC:  X(4) 

DESC:  Identifies  date  document  or  requisition  was  established. 
The  left  most  digit  is  the  units  digit  of  the  current 
year  and  the  right  three  are  the  numeric  equivalent  of 
the  day  of  the  year. 

USED  IN:  AMRE£UIS,AMTURNIN 

REFS:  (a),(b) 

DEN:  A045 

NAME:  LOCATION 

LONG  TITLE:  Activity  Long  Name  Location 

PIC:  X(30) 

DESC:  Plain  Language  Address  of  activity  or  ship  in  overhaul 

or  a  precommissioned  vessel. 
USED  IN:  AMDADDR 
REFS: 

DEN: 

NAME:  LCGIN_NAME 

LONG  TITLE:  Log- in  Name 

PIC:  X(8) 
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DESC:  An  eiaht  character  name  that  must  be  entered  properly 
by  the  user  of  SAMS  for  the  security- functions  of  the 
system  to  recognize  him  as  a  legal  user  and  allow 
access  to  the  system. 

USED  IN:  DBSYSTEM 

REFS: 

DEN: 

NAME:  LONGTITLE 

LONG  TITLE:  Long  Title  (Local  SAMS  data  element) 

PIC :  memo 

DESC:  Official  description  of  ammunition  data  as  described 

in  Stock  List  of  Navy  Ammunition,  TWO10-AA-ORD-010  (SPCC) 
USED  IN:  AMMODATA 
REFS: 

DEN: 

NAME:  LONGTITLE 

LONG  TITLE:  Data  Element  Long  Title 

FIC:  X(55) 

DESC:  The  full  title  of  the  data  element  as  used  in  the  SAMS. 

USED  IN:  DATAELEM 

REFS  : 

DEN:  C301 

NAME:  LOTNUMBER 

LONG  TITLE :  Ammunition  Lot  Number 

PIC:  X(16) 

DESC:  A  number  assigned  at  the  time  of  manufacture  or 
assembly  to  identify  a  group  of  rounds  of 
ammunition,  each  component  of  which  is  manufactured 
by  one  manufacturer  under  uniform  conditions  and 
which  is  expected  to  perform  in  a  uniform  way. 

USED  IN:  AMINVEN,AMTURNIN,AMTRANS,AMNARACT 

REFS: 

DEN:  C003A 

NAME:  MATLCONCOD 

LONG  TITLE:  Material  Control  Code 

PIC:  A 

DESC:  The  Material  Control  Code(MCC)  is  a  single  alphabetic 
character  assigned  by  the  Inventory  Manager  to 
indicate  to  field  activities  that  special  reporting 
or  control  requirements  may  be  necessary.  Used  in 
CAIMS  to  indicate  SLIT  controlled  item. 

USED  IN:  AMMODATA 

REFS: 

DEN:  C026 

NAME:  MDD 

LONG  TITLE:  Maintenance  Due  Date 

PIC:  X(3) 

DESC:  The  month  and  the  year  of  the  next  scheduled 

maintenance  on  the  item  of  record(MYY) .  MDD  is 
assigned  to  serial  number  and  serial  and  lot  number 
controlled  items  only. 

USED  IN:  AMINVEN,AMTRANS 

REFS: 

DEN:  K082 

NAME:  MEDIASTAT 

LONG  TITLE:  Media  and  Status  Code 

FIC:  X 

DESC:  The  Media  and  Status  Code  is  a  single  character 

indicating  the  type  of  supply  status  required  and 
the  method  in  which  it  is  to  be  furnished. 

USED  IN:  AMREQUIS 
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REFS:  (a)/(b),(c),(d) 

DEN:  C076 

NAME :  HESSAGEDTG 

LONG  TITLE:  Naval  Message  Date-Time-Group 
PIC:  X(14) 

DESC:  The  standard  means  of  identifying  a  naval  message: 

The  DTG  identified  the  day,  the  hcur(24  hour  clock), 
Z(Zulu  time),  the  month,  and  decade/year  of  transmittal. 

USED  IN:  AMTRANS 

REFS: 

DEN: 

NAME :  MONITACTIV 

LONG  T-TLE:  Monitoring  Activity  (SAMS  local  data  element) 

PIC:  X 

DESC:  The  shore  logistic  or  operational  command  which  monitors 
a  ships  logistics  traffic  and  transaction  reports.  It  is 
used  in  conjunction  with  the  Cognizance  Symbol  to  form 
the  Distribution  Code. 

USED  IN:  AMSTDATA 

REFS: 

DEN:  CC03C 

NAME:  NALC 

LONG  TITLE:  Naval  Ammunition  Logistics  Code 

PIC:  X(4) 

DESC:  The  NALC  is  a  four  character  alphanumeris  assigned  by 
SPCC  to  conventional  ammunition  items  which  do  not 
meet  the  established  DoD  criteria  for  DODAC  assignment. 
Application  of  NALC  and  DODAC  are  identical. 

USED  IN:  AMMCDATA,  AMALLOW 

REFS  : 

DEN : 

NAME:  NAME 

LONG  TITLE:  Name  of  data  element 

PIC:  X(10) 

DESC:  The  name  of  a  data  element  in  the  SAMS. 

USED  IN:  DATAELEM 
REFS: 

ce:;: 

name:  nameofprog 

LONG  TITLE :  Name  of  Program 

PIC:  YJS) 

IZ5C:  The  name  of  a  program  used  in  the  SAMS. 

USED  IN:  CONTFILE 

REFS: 

DEN:  CC73 

NAME:  NARDTG 

LONG  TITLE:  Notice  of  Ammunition  Reclassification  Date-Time-Group 

PIC:  X(14) 

DESC:  The  Date-Time-Group  of  the  NAR  message 

USED  IN:  AMNARSER 

REFS: 

DEN : 

NAME:  NARREMARKS 

LONG  TITLE:  Notice  of  Ammunition  Transaction  Remarks  (SAMS  LDE) 

PIC:  X(40) 

DESC:  Statement  concerning  the  condition  of  affected 

ammunition  following  a  NAR  action  and/or  the  reason  for 
the  NAR  action;  normally  explained  on  the  NAR  itself. 

USED  IN:  AMMARACT 
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REFS: 

DEM:  CO 84 

NAME:  NARSERIAL 

LONG  TITLE:  Notice  of  Ammunition  Reclassification  Serial  Number 

PIC:  9(3) 

DESC:  One  of  two  sub-elements  comprising  the  NAR  Number. 

NAR  serial  serves  the  two-fold  purpose  of  collecting 
all  items  reclassified  by  a  NAR  action  and  identifying 
the  number  of  reclassification  actions  released 
during  a  given  vear. 

USED  IN:  amiurnin,amnaP.ser,amnaract 

RErS  : 

DEN:  C083 

NAME:  NARYEAR 

LONG  TITLE:  Notice  of  Ammunition  Reclassification  Year 

PIC:  99 

DESC:  One  of  two  sub-elements  comprising  the  NAR  Number. 

NARYEAR  identifiees  the  decade  and  year  in  which  the 
Notice  of  Ammunition  Reclassification(NAR)  was  released. 

USED  IN:  AMTURNIN,AMNARSER, AMNARACT 

REFS: 

DEN:  C304E 

NAME :  NETEXPLWT 

LONG  TITLE:  Net  Explosive  Weight 

PIC:  X(10) 

DESC:  The  total  weight  of  all  active  explosive  components  of 

an  explosive  device  which  includes  primary  explosives, 

secondary  explosives,  pyrotechnics,  and  propellants. 

Data  should  be  expressed  in  whole  numbers 

with  the  units.  (50  LB.,  25  KG.) 
USED  IN:  AMMODATA 
REFS: 

DEM:  C003E 

NAME :  NEWCONDCD 

LONG  TITLE:  New  Condition  Code 

PIC:  A 

DESC:  The  Condition  Code  of  ammunition  items  involved  in  a 

transaction  after  their  change  in  Condition  Code  as  a 

result  of  the  transaction. 
USED  IN:  AMNARACT 
REFS: 

DEN:  DC46D 

NAME:  MI IN 

LONG  TITLE:  National  Item  Identification  Number 

PIC:  X(9) 

DESC:  A  nine-position  non-significant  number  assigned  by  the 

Defense  Logistic  Services  Center  to  each  approved  item 
identification  under  the  Federal  Cataloging  Program. 

USED  IN:  AMREQUIS, AMMODATA , AMINVEN , AMTURNIN , AMTRANS , AMNARACT 

REFS:  (a),(b) 

DEN:  C003E 

NAME:  OLDCONDCD 

LONG  TITLE:  Old  Condition  Code  (SAMS  local  data  element) 

PIC:  A 

DESC:  The  Condition  Code  of  ammunition  items  that  are  involved 
in  a  transaction  prior  to  their  change  in  Condition  Code 
as  a  result  of  the  transaction. 

USED  IN:  AMNARACT 

F.EFS  : 
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DEN: 

NAME:  PASSWORD 

LONG  TITLE:  Password 

PIC:  X(16) 

DESC:  A  sixteen  character  password  of  any  case  that  must  be 
entered  properly  by  the  user  of  SAMS  in  order  for  the 
security'  functions" of  the  system  to  recognize  him  as 
a  legal  user  and  allow  access  to  the  system. 

USED  IN:  DBSYSTEM 

REFS  : 


::a::e 

l::;c 

PIC: 
DESC 

USED 
REFS 


PICTURE 
TITLE:  Picture  of  a  data  element 
:■:  ( 5 ) 

The  type  of  the  data  element,  ie  (X)character , 
(9)numeric,  etc.  and  the  length  of  the  data  element. 
IN:  DATAELEM 


DEN: 
NAME 
LCNG 
PIC: 

DESC 


USED 

REFS 


K025 
:  PRIORITYCD 

-ITLE:  Priority  Code  (Issue-Priority-Designator) 

99 
:  A  series  of  two-digit  numeric  cedes  assigned  by  the 

originator  cf  the  document  which  expresses  the  relative 
importance  of  the  requisitioned  material  movement  and 
the  military  urgency  of  the  material  movement  and 
issue  transactions. 

IN:  AMREQUIS 


DEN: 

NAME :  PROG_NAME 

LONG  TITLE:  Program  Name 

PIC:  X(8) 

DESC:  Name  of  a  program  in  the  SAMS. 
USED  IN:  PROGFILE 
REFS  : 


DEN: 

NAME 
LCNG 
PIC: 

DESC 


USED 
REFS 


K024 
PROJCODE 

TITLE:  Project  Code 
X(3) 
A  cede  assigned  by  the  military  services  or  DoD  to 
identify  a  specific  project  of  a  general  or  special 
program  nature  for  recognition  through  out  the 
distribution  svstem. 
IN :  AMREQUIS , AMTURNIN 
(a) , (b) , (c) 


::a::E:  purpose 

LCNG  TITLE :  Purpose  of  a  program 

PIC:  X(70) 

DESC:  The  puroose  of  a  program  in  the  SAMS. 
USED  IN:  PROGFILE 
REFS  : 

DEN: 

NAME:  QUANTITY 

LONG  TITLE:  Quantity 

PIC:  X(5) 

DESC:  Quantity  in  per  unit-of-issue  amounts.  For  quantities 

greater  than  99999,  use  an  M  in  the  rightmost  digit  to 
indicate  thousands.  Normally  all  positions  should  be 
filled  in,  including  leading  zeros. 
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USED  IN:  AMREQUIS, AMINVEN,AMTURNIN,AMTRANS,AMALLOW 
REFS: 

DEN: 

NAME:  REFERENCE 

LONG  TITLE:  Data  Element  References 

PIC:  X(70) 

DESC:  The  Navy  or  Supply  publications  which  fully  describe 

the  puroose  and  use  of  a  data  element. 
USED  IN:  DATAELEM 
REFS  : 

DEN:  K01S 

NAME:  REQDELDATE 

LONG  TITLE:  Required  Delivery  Date 

PIC:  999 

DESC:  When  used  on  a  requisition,  this  element  consists  of 
a  three-digit  Julian  date  which  indicates  the  date 
that  the  material  is  required  by  the  requisitionee . 

USED  IN:  AMREQUIS 

REFS  : 

DEN: 

NAME:  REQUISSTAT 

LONG  TITLE:  Requisition  Status  (SANS  local  data  element) 

PIC:  X(A) 

DESC:  A  local  system  code  to  indicate  the  status  of  a 

requisition  action,  ex. incomplete ,  ready, 

submitted-nct-filled,  etc. 
USED  IN:  AMREQUIS 
REFS: 

DEN:  A001 

NAME:  ROUTIDENT 

LONG  TITLE:  Activity  Routing  Identifier 

PIC:  X(3) 

DESC:  A  three  diait  alphanumeric  or  alphabetic  code 

assigned  to  Inventory  Control  Point,  Inventory 
Managers,  Distribution  Points {  and  designated  storage 
points.  Used  to  indicate  the  intended  recepient,  the 
actual  shipper,  or  action  orig.  activity 

USED  IN:  AMDADDR 

REFS: 

DEN:  C017 

NAME:  SECRISKCOD 

LONG  TITLE:  Security  Classification  Code 

PIC:  X 

DESC:  This  code  designates  the  degree  of  physical  security 

assigned  to  an  item  of  supply. 
USED  IN:  AMMODATA 
REFS: 

DEN:  K043 

NAME:  SEMDTOSERC 

LONG  TITLE:  Service  Designator  Code  (of  requisitionee) 

PIC:  X 

DESC:  Service  Designator  Code  of  requisitionee,  PAC,  LANT, 
etc..  A  code  that  identifies  a  service  or  element  of 
a  service. 

USED  IN:  AMREQUIS 

REFS:  (a),(b),(c),(d) 

DEN:  AC02 

NAME:  SENDTOUIC 

LONG  TITLE:  Unit  Identification  Code  of  requisitionee 
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PIC:  X(5) 

DESC:  UIC  of  requisitionee.  Identifies  a  ship  or  shore 

activity  uniquely  in  the  manner  specified  by  individual 
military  services  for  accounting  and  other  purposes. 

USED  IN:  AMREQUIS  ^ 

REFS:  (a),(b) 

DEN:  K002C 

::.-.::i:  serial 

LONG  TITLE:  Requisition/Turn-in  Serial  Number 

FTC:  9(4) 

LE5C:  The  portion  of  the  Document  Number  (DEN  K002)  which 
applies  10  the  serial  number  of  the  document.  Under 
CAIMS,  ships  use  sequential  numbers  8000-8999  and  then 
reoeat  when  necessary. 

USED  IN:  AMREQUIS ,AMTURNIN 

REFS:  (a),(b),(c) 


DEN:  D330 

::a::e:  sernumber 

Component  Serial  Number 


long  title 

PIC:  X(16) 

DESC 


An  identification  number  given  to  each  item 
manufactured  within  a  particular  lot  of  a  given 
stock  number. 

USED  IN:  AMINVEN 

REFS: 

DEN:  K048 

NAME:  SERVCODE 

LONG  TITLE:  Service  Code 

PIC:  X 

DESC:  A  code  that  identifies  a  service  or  element  of  a 

service . 
USED  IN:  AMDADDR,AMSTDATA 
REFS: 


DEN:  A002 

NAME:  SHIPTOUIC 

LONG  TITLE:  Unit  Identification  Code  of  receiving  activity 


PIC: 

DESC 


X(5) 


Identifies  a  ship,  shore  activity,  operational  unit, 
agency,  contractor,  or  other  organized  entity  in  the 
manner  specified  by  the  individual  military 
service/agency  for  accounting  or  other  purposes. 

USED  IN:  AMTURNII-I 
REFS: 


DEN: 

MAKE:  SHORTTITLE 

LONG  TITLE:  Short  Title  of  ammunition  item  (SAMS  data  element) 

PIC:  X(20) 

D-SC:  Short  description  of  ammunition  item  for  quick 

reference. 
USED  IN:  AMMODATA 
REFS: 


DEN:  K021 

NAME:  SIGNALCODE 

LONG  TITLE:  Signal  Code 
X(A) 
This  code  designates  the  fields  (card  columns)  which 
contain  the  intended  consignee  (ship  to)  and  the 
activity  to  receive  the  bills  and  effect  oayment 
(bill  to). 

USED  IN:  AMREQUIS 

REFS  : 


PIC : 

DESC 
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DEM: 

NAME:  SOURCR_FIL 

LONG  TITLE:  Source  File  of  the  data  element 

PIC:  X(50) 

DESC:  The  files  (relations)  in  which  the  data  element 

is  used. 
USED  IN:  DATAELEM 
RE  rS  : 

DEM: 

NAME:  STORAGELC 

LONG  TITLE:  Storage  Location   (SAMS  local  data  element) 

PIC:  X(30) 

DESC:  The  location  onboard  a  ship  where  particular 

ammunition  items  are  stored,  ex.  small  arms  locker, 
ready  service  locker,  Magazine  (compt.  number),  etc. 
USED  IN:  AMIMVEM 
REFS: 

DEM:  K048 

NAME :  SUPADDSERC 

LONG  TITLE:  Service  Designator  Code  of  loadout  activity 

PIC:  X 

DESC:  Supplemental  Address  Service  Designator  Code,  loadout 
point.  A  single  alpha  code  that  designates  a  service 
or  element  or  a  service. 

USED  IN:  AMREQUIS 

REFS: 

DEM:  A002 

NAME:  SUPADDUIC 

LONG  TITLE:  Unit  Identification  Code  of  loadout  activity 

PIC:  K(5) 

DESC:  Supolemental  Address  UIC,  loadout  point  UIC. 

Identifies  a  ship  or  shore  activity  uniquely  in 
the  manner  specified  by  its  service  for  accounting 
and  other  purposes. 

USED  IN:  AMREQUIS 

REFS  : 

DEM  -. 

NAME:  TAGLABEL 

LONG  TITLE:  Tag  Label  (SAMS  local  data  element) 

PIC:  X(30) 

DESC:  A  short  narrative  that  is  placed  on  the  label  that 
must  be  attached  to  MAR  affected  ammunition  to 
explain  the  conditions  under  which  it  may  be  used 
or  if  it  may  be  used  and  to  segregate  it  from  other 
unrestricted  use  ammunition. 

USED  IN:  AMNARACT 

REFS: 

DEN:  CO 10 

NAME:  TMDC 

LONG  TITLE:  Type  of  Maintenance  Due  Code 

PIC:  A 

DESC:  A  code  indicating  the  type  of  maintenance  to  be 
performed  on  the  item  of  record.  Applies  to 
torpedo  MK  46  and  ALM  (Air  launched  Missiles). 

USED  IN:  AMMCDATA 

REFS  : 

DEN: 

NAME:  TRMGALLOW 

LONG  T.TLE:  Training  Allowance  (SAMS  local  data  element) 
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PIC:  9(5) 

DESC:  The  unit-of-issue  quantity  of  a  particular  ammunition 
item  that  a  ship  or  unit  is  autnorized  to  expend  in 
a  fiscal  vear  for  training.  Promulgated  in  the  30000 
series  NAr/SEA  Shiofill  Allowance  List. 

USED  IN:  AMALLOW 

REFS  : 

DEN: 

NAME :  TURNINSTAT 

LONG  TITLE:  Turn-in  Document  Status  (SAMS  local  data  element) 

PIC:  A 

DESC:  The  status  of  a  turn-in  record  line  item, 

ex. -incomplete ,  ready  to  print  or  use  as  an  input 

to  an  ATR,  or  ATR  action  complete. 
USE:  IN:  AMTURIN 
REFS: 

DEN:  A002 
NAME:  UIC 

LONG  T-TLE:  Unit  Identification  Code 

PIC:  X(5) 

DESC:  Identifies  a  ship,  shore  activity,  operational  unit, 
agency,  contractor,  or  other  organized  entity  in  the 
manner  specified  by  the  individual  military 
service/agencies  for  accounting  or  other  purposes. 

USED  IN:  AMDADDR,AMSTDATA 

REFS: 

DEN:  D192 

NAME:  UNITNAME 

LCNG  TITLE :  Activity  Long  Name  (own  ship) 

PIC:  X(45) 

DESC:  Name  of  own  ship  as  listed  in  the  Plain  Language 

Address  Directory  (PLAD)  if  available,  otherwise 

in  the  clear  name. 
USED  IN:  AMSTDATA 
REFS: 

DEN:  C005 

NAME:  UNITOFISSU 

LONG  TITLE:  Unit  of  Issue 

PIC:  AA 

DESC:  An  abbreviation  which  represents  a  determinate 
amount  or  quantity  and  serves  as  a  unit  of 
measurement  when  issueing  the  item,  ex.  BX,EA,etc. 

USED  IN:  AMHODATA 

REFS: 

DEN:  B052 

:;a::e-  [jnitprice 

LONG  TITLE:  Unit  Price 

PIC:  9(10) 

DESC:  The  price  of  the  individual  item  of  supply  per 
unit  of  issue. 

USED  IN:  AMMODATA 
REFS: 

DEN: 

NAME:  USED/ FY 

LCMG  TITLE:  Training  Allowance  used  in  current  fiscal  year  (LDE) 

PIC:  9(5) 

ZZSZ-.   The  quantity  of  a  particular  ammunition  item  that  has 
a  training  allowance  that  has  been  expended  in  the 
current  fiscal  year  for  that  purpose. 

USED  IN:  AMALLOW 
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APPENDIX  C 
SAMS  PROGRAM  DIRECTORY 

Program:    AMSMAIN 

Calls  :      INFOMENU , INVMENU , TRANMENU , REQMENU , NARSMENU , REPTMENU , 

MAMGMENU , TURNMENU 
Purpose:   Main  prg.  that  branches  to  ail  subsystem  menus, 

intro.  screen. 
Called  By:  PROTECT   (dBase  III+  security  program) 

Program:    BCKUPATR 

Calxs :     none 

Purpose:   Backups  ATR  file  to  another  storage  device  for  system 

protection. 
Called  By:  TRANMENU 

Program:   BCKUPNAR 

Calls :     none 

Purpose:   Backups  NAR  Serial  and  Action  File  for  system 

protection. 
Called  By:  NARSMENU 

Program:    3CKUPREQ 

Calls:     none 

Purpose:   Eackups  Requisition  File  to  another  storage  device 

for  sys .  protection. 
Called  By:  REQMENU 

Program:  BCKUPSYS 

Calls :  none 

Purpose:  Allows  system  manager  to  bacup  all  system  files. 

Called  By:  MANGMENU 

Program:    BCKUPTUR 

Calxs :     none 

Purpose:   Backups  Turn-in  File  to  another  storage  device  for 

sys'tem  protection. 
Called  By:    TURNMENU 

Program:   CCMPLREQ 

Calls.-     none 

Purpose:   Offers  detailed  review  of  requis.  with  all  pertinent 

data . 
Called  By:  REQMENU 

Program:  CRENEWRQ 

Calls:  none 

Puroose:  Creates  new  requis.  with  detailed  user  instructions 

Called  By:  REQMENU 

Program:  CRENWATR 

Calls :  none 

Purpose:  Allows  user  to  create  an  ATR  record,  collects  all  data 

Called  By:  TRANMENU 

Program:  CRENWTID 

Calls:  P.EVWADD 

Puroose:  Creates  a  turn-in/issue  line-entry. 

Called  BY:  TURNMENU 
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Program:  DATAELEM 

CalxS:  none 

Purpose:  Allow  the  user  to  review  the  Data  Element  Dictionary 

of  the  SAKS. 

Called  By:  INFOMENU 

Procram.-  DOCCODES 

Calls :  none 

Purpose:  Presents  system  and  CAIMS  codes. 

Called  3y:  INFOMENU 

Program:  DOCDEFIN 

Calls:  none 

Purpose:  Presents  system  and  CAIMS  definitions. 

Called  By:  INFOMENU 

Program:  DOCFILES 

Cal_s:  none 

Purpose:    Presents  SAMS  files  and  their  purpose. 

Called  3v:  MANGDOC 


Program:  DOCPRGS 

Cal_s :  none 

Purpose:  Presents  SAMS  programs  and  their  purpose. 

Called  By:  MANGMENU 

Program:  DOCREFS 

Calls:  none 

Purpose:  Presents  system  and  CAIMS  reference  documents. 

Called:  INFOMENU 

Program:  EDITATR 

Calis :  none 

Purpose:  Allows  use  to  edit  or  delete  non-committed  ATR's. 

Called  By:  TRANMEMU 

Program:  EDITREQ 

Cal.s :  none 

Purpose:  Allows  editing  and  deleting  of  non-submitted 

requisitions . 

Called  3y:  RECMENU 

Program:  EDITTURN 

Calls:  none 

Purpose:  Allows  editing  or  deleting  of  non-submitted  turn-in/ 

issue  document. 

Called  3y:  TURNMEMU 

Program:  INFOHELP 

Calls:  none 

Purpose:  Provide  system  operating  help  accessible  throughout 


program. 
Called  By:  INFOMENU 


Program:  INFOMENU 

Calls  :  INFOTEXT , INFOHELP , DOCCODES , DOCDEFIN , DOCREFS , DATAELEM 

Puroose:  Gives  general  system  info,  and  help  programs. 

Called  By:  AMSMAIN 

Program:    INFOTEXT 
Calls:     none 

Purpose:   Give  general  system  purpose , operation,  and  other 
information. 
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Called  By:  INFOMENU 

Prograqm:  INVALLOW 

Calls :  none 

Purpose:  DisDlays  Allowance  List  information  to  SAMS  user. 

Called  By:  INVMENU 

Program:  INVAMMO 

Calls :  none 

Purpose:  Allows  user  to  review  generic  ammunition  data 

Called  By:  INVMENU 

Program:    INVMENU 

Calls  :      INVVIEW, INVAMMO , INVALLOW 

Purpose:   Allows  user  to  review  generic  ammo  data, inventory 

status , allowance . 
Called  By:  AMSMAIN 

Program:    INVREPT 

Calls:     none 

Purpose:   Prints  various  inventory  reports  depending  on  user 

desires . 
Called  By:  REPTMENU 

Program:    INWIEW 

Calls:     none 

Purpose:   Allow  user  to  review  onboard  inventory  with  various 

field  items. 
Called  By.  INVMENU 

Program:   MANGADHC 

Calls:     none 

Purpose:   Allows  administrator  to  create  ad  hoc  queries  and 

views . 
Called  By:  MANGMEMU 

Program:  MANGARCH 

Calls :  none 

Purpose:  Allows  administrator  to  archive  old  records. 

Called  By:  MANGMENU 

Program:   MANGDOC 

Calls :      DOCFILES , PROGFILE , STRUCCRT 

Purpose:   Allows  system  manager  to  select  various  documentation 

files  for  view. 
Called  By:  MANGMENU 

Program:   MANGEDIT 

Calls :     none 

Purpose:   Allows  administrator  to  globally  edit  and  deleLe 

system  records. 
Called  By:  MANGMENU 

Program:   MANGINIT 

Calls:     none 

Purpose:   Start-up  and  initialization  instructions  for 

administrator. 
Called  By:  MANGMENU 

Program:   MANGMENU 

Calls  :      MANGEDIT , MANGSEC , MANGARCH , MANGRECV , MANGADHC , 

MANGINIT , BCKUPSYS , DOCFILES , DOCPRGS 
Purpose:   Selects  type  of  system  management  desired 

by  system  administrator. 
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Called  By:  AMSMAIN 

Program:  MANGRECV 

Calls:  none 

Purpose:  Allows  administrator  to  recover  system  from  failure. 

Called  By:  MANGMENU 

Program:  MANGSEC 

Calls:  PROTECT  (dBase  III+  security  program) 

Purpose:  Allows  administrator  to  manage  security  and 

access  system. 

Called  By:  MANGMENU 

Program:  MISCREQ 

Cal_s :  r.cne 

Purpose:  Refers  user  to  other  doc.  for  abnormal  requis. 

operations 

Called  3y:  REQMENU 

Program.-  NARSMENU 

Calls  :  REVNARSF , REVNARAF , PROCMAR , BCKUPMAR 

Purpose:  Allows  review  of  MAR  f ile , stcckcheck,  action 

file  uodate,  backup 

Called  By:  AMSMAIN 

Program:  OSRQREPT 

Calls .-  none 

Purpose:  Prints  outstanding  requisition  internal  reports. 

Called  By:  REPTMENU 

Program:  PRINTATR 

Calls:  none 

Purcose:  Allows  printing  of  the  various  types  of  ATR's. 

Called  By:  TRANMENU 

Program:  PRINTREQ 

Cai^s:  REQ1348,REVWADD 

Purpose:  Allows  printing  of  differant  requisition  formats 

Called  By:  REQMENU 

Program:  PRINTTUR 

Calls:  none 

Purpose:  Prints  turn-in  document. 

Called  3y:  TURNMENU 

Program:  PROCNAR 

Calls :  none 

Purpose:  Processes  NAR  message:  stock  check,  update  inventory, 

retain  data 

Called  By:  NARSMENU 

Prcgram:  PROGFILE 

Calls:  none 

PurDOse:  Allows  user  to  review  and  print  system  program  file. 

Called  By:  MANGDOC 

Program:  REPTMENU 

Calls:  IMVREPT, OSRQREPT, TRALREPT 

Purpose:  Prints  various  internal  system  reports. 

Called  By:  AMSMAIN 

Program:  REQ1343 

Calls :  none 

Purpose:  Prints  screen  display  of  DD  Form  1348  with 
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data  filled  in. 

Called  By:  PRINTREQ 

Program:  REQMENU 

Calls :  REVWREQ , COMPLREQ , CRENEWRQ , EDITREQ , MISCREQ , PRINTREQ , 

BCKUPREQ 

Pumose  :  Branches  to  all  requisition  processing  sub-functions 

Called  By:  AMSMAIN 

Program:  REVNARAF 

Calls:  r.or.e 

Purpose:  Allows  user  to  review  the  NAR  Action  File. 

Called  By:  NARSMENU 

Program:  REVNARSF 

Calls :  none 

Purpose:  Allows  user  to  review  the  NAR  Serial  File. 

Called  By:  NARSMENU 

Program:  REVWADD 

Calls :  none 

Puroose:  Allows  user  to  review  address  file. 

Called  3y:  PRINTREQ, PRINTATR, CRENWTID 

Program:  REVWREQ 

Calls:  none 

Purpose:  Offers  summary(exec. )  review  of  all  requis.  with 

most  imp.  data. 

Called  By:  REQMENU 

Program:  STRUCCRT 

Calls :  none 

Purpose:  Allows  system  manager  to  review  the  SAMS  design 

structure  charts. 

Called  By:  MANGDOC 

Program:  TRALREPT 

Calls:  none 

Puroose :  Prints  Training  Allowance  internal  reports. 

Called  By:  REPTMENU 

Program:  TRANMENU 

Calls  :  VIEWATR , CRENWATR , EDITATR , PRINTATR , BCKUPATR 

Purpose:  Selects  type  of  ATR  management  desired. 

Called  By:  AMSMAIN 

Program:  TURNMENU 

Calls :  TURNREV , CRENWTID , EDITTURN , PRINTTUR , BCKUPTUR 

Purpose:  Selects  type  of  turn-in/issue  management  desired. 

Called  By:  AMSMAIN 

Program:  TURNREV 

Calls:  none 

Purpose:  Allows  review  of  turn- in  file. 

Called  By:  TURNMENU 


Program:    VIEWATR 
Calls:     none 


Purpose:   Allow  user  to  review  the  ATR  file 
Cal-ed  By:  TRANMENU 
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APPENDIX  D 
SAMS  STRUCTURE  CHARTS 


1 

1 

NARS 
Management 
"NARSMENU " 

7.0 

System 
Managemen  t 
"MANGMENU  " 

8.0 

Generate  Int. 
Reports 
"REPTMENU " 

9.0 

Turn-in  Doc. 
Manageme  n t 
"TURNMENU " 

6.0 

User  Access/ 
Va 1 ida t  ion 
" PROTECT" 

1.0 

Requisition 
Management 
"REQMENU " 

5.0 

In v . / A  1 low . 
Ammun  .   Info. 
"INVMENU " 

3.0 

Gene  ral  Info./ 
Documentation 
"  INFOMENU" 

2.0 

Transact  ion 
Manageme  n  t 
"TRANMENU  " 

4.0 

< 

Shipboard  Ammuniton  Management  Svsvtem 
Major  Subsystems 

127 


\ 

U) 

: 

V)    G    - 

3    Z 

ill    0    f^^ 

C    H 

0  -H    U  O 

U   JJ    u 

2    2             • 

<    (T3    £-.   "**• 

Cfl 

T3    O 

C   2 

i-l    -rH     Qi 

■H     < 

Q)   r-t    04 

<fl    : 

en    <TJ    = 

2 

D  > 

User  Access  /  Main  Menu 


128 


Ul  = 

U  Cn 

S     G  U 

a)    o)  ce; 

jJ     i-i  u 

01    a)  O 

>.  u-i  a 

Ul     U  : 
OS 


01  = 

c  -z 

0  M 

in  -h  t, 

2     JJ  DJ 

hh  -h  a 

<   c  u 

u  -H  o 

H-l  Q 
Q 


>,  2 

^    M 

«  J  vo 

aj    c   u        . 

Q    JJ    <C 

u  a 

■H    = 

a 

Ul 

0) 

CO 

T3 

w 

0 
U 

a  ro 
g   CNJ 

w 

u 

2 

o 

H 

a 

4 

: 

u 

0    E- 

■H    X 

: 

g      4J       U. 

a, 

J)        ftt^           . 

J 

JJ   -H    O  C\J 

CJ     C\] 

W     M    fa 

O    CVJ 

>i   u   z 

CO     01     H 

w 

fa 

a>  = 

X 

•z 

H 

a 

General  Information  /  Documentation 


129 


0 

u-i   : 
>i   C    3 

fl    H    O 

■      0-i     •    >— ' 

U5      3     <     f«"\ 

•H      0     >         ' 

Q      H      Z 

In  v . / Al low . 
Ammun  .  Info. 
" INVMENU  " 

3.0 

Display 
Ammun .  Data 
"  INVAMMO" 

3.2 

Di  splay 
In ve  n tor y 
"INVVIEW" 

3.1 

Inventory 

,  Allow; 

ince,  Ammu 

nition  Data 

130 


3 

&4 

<D 

•H 

01 

> 

tt 

<D 

CD 

oS 

u 

n 

T3 

< 

<  to 

>  ^f* 


0    *J     D 

0) 

■H     C    Z 

-U          : 

ii    11   j] 

d)           OS 

«    «   Z        . 
c   <d  05 

/Del 
ATR 
I  TAT 

4.3 

fl     S    f" 

■U            Q 

1-1     (0    S 

■H            U 

E-    £ 

T3          : 
Ed 

X 

3     <U    OS 

eate 

ATR 
NWAT 

4.2 

(1)     ^H    E-i 
•H    -H    < 

<y           Cd    ^ 

U          Cd 

os  os  h 

U           OS 

E-    > 

u 

<    : 

■ 

Transaction  Management 


131 


c 

0 

•U 

: 

•H 

c 

3 

0) 

Ul 

<D 

5  ^ 

■<-i 

Di 

ex     ' 

3 

03 

fa 

■y 

B 

BJ 

V 

ra 

: 

o4 

2 

(J 

0 

ui 

14-1 

•H 

C    = 

2 

M    CX 

a 

iO 

>1 

•    04 

03 
H 

ui  U 

•H     Ul 

«■> 

Q| 

3      M 

Ul 

cr  s 

■H 

0)    : 

a 

04 

aj 

c 

-u 

0    = 

a; 

•H    CX 

r-i 

+J    fa 

Q 
\ 

■H    04 

en  E-> 

•H     M 

^3- 

+J 

3  a 

■H 

tr  h 

T3 

0)    = 

fa 

Si 

3 

U 
03 

CQ 


0) 

u 


<u  = 

r-4      CX 

•H    fa 

fa    05  <£ 

—  • 

3  IT) 

■H    U 

3    CQ 

a1  = 

04 


U] 


M 

a. 


CX 

w 

C4 


cr  a. 
oj  = 

04 


j->    c/i    E-i 

3     W    M 

f"0 

0    OJ    fa 

K' 

i    XJ    J 

r-4.     g     fa 

lO 

-H     3     Q- 

a)  z  ui 

a      = 

CO 

CD 

r-l 

: 

•H 

Q 

3 

fa 

a 

c\j 

(1) 

Ul 

< 

3 

K 

> 

Ul 
1) 

> 

fa 

iO 

04 

S-l 

04 

T3 

: 

TD 

< 

U 

03 

e 

u  = 

rH 

0    CO 

03 

fa  ■*  **■"" 

'      3 

m  jv: 

a 

»    »H 

03 

to   CxU") 

2 

■H    W 

3    04 

a1  = 

<u 

□4 

en 

03 

C    = 

■H 

•H 

o  cx 

3    —   = 

3 

■H    04 

CT  TJ    CX 

cr  —  = 

OJ    +J    3 

OJ     OJ    u     ^ 
04    H    04     ^M 

OJ     >  CX 

4J    -H    fa 

n 

04     U    W    "** 

o3    cn   Z 

• 

■H    J          ' 

fl   *   .^" 

OJ    -H    fa 

U"> 

3    03   a,    *0 

JES'O 

U     3    04 

OJ    4J    2 

oj    S  > 

U     D1  U 

•H     OJ    o 

•H     3    fa 

OJ    = 

>   T3   U 

>    ui   Q4 

04 

04 

04 

Requisition  Management 


132 


'J        - 

0  -U    3 

QS3o 

s  e  s 
■h    a   z   ^ 


"3    ~ 
C    Eh 


-    X 


*J  0  2 

0)  Q  2S 

y  =  Eh 

Q  -H  Eh 

\  I  H 

-J  3  — 

— I  U  M 

T3  3  = 

Cs3  E- 


O 

O 

a 


<*6 


X 

u 

: 

u 

0 

X 

fl 

a 

~ 

CQ 

■- 

c 

a, 

<V 

•m 

- 

4J 

i 

x. 

aj 

c 

u 

<D 

u 

CD 

U 

3 

: 

U 

Eh 

10 


CVJ 
CO 


3 

<u 

■•H 

> 
(1) 

OS 


> 

3  a 

■h  as 

i  z 

s  as 

3     E-> 


CO 


Turn-in  Document  Management 


133 


u  a 

c  z 

en 

OS 
< 

0)    Cd 

e  s 
0)  en 

en  qs 

O 

Z 

n3    < 

C    Z 

2 

cu 

a 

^ 

U           = 

nj    10    OS 

h  z   ^r 

cu  -h   ai  fv^ 

■P    Cu    D 

id        ^ 

0)    OS   CJ 

M    <    03 

CJ    Z    : 

3 

0) 

cu 

z 

a* 

r 

m 

o; 

10 

CO 
CO 

cu 

< 
z 

CJ 

u 

■2. 

a 

0 

OS 

u 

X 

04 

cu 

z 

Review  NAR 

Act  ion  File 

"REVNARAF" 

7.2 

Review  NAR 
Serial  File 
"REVNARSF" 

7.1 

NARS  Management 


134 


o    • 

• 

: 

■H    -U 

>,    U    : 

U 

4J     01    : 

03     0    U       , 

0)    SC 

03     G    t-> 

r-l       Q       O          VS 

CJ     <U    Q 

M     1— 1      M 

0    -H    <  fv 

•H            Z 

00 

X     MO. 

.-I      3j    M 

•H     0)    z 

ai   zQq 

03    3    a 

ob 

C     4J     <C 

13    a  < 

•H    -U    Z 

'Si    2 

<  c*% 

+J     u    < 

>i  = 

: 

■<- t     03    2 

CO 

C    4J    = 

H    CO 

> 

U        u 

0)    s   w 

>     5)    2      ^O 

U     l»    z     ^ 

OJ     >.  < 

X    05    2 

JJ    : 

: 

a  a 

e 

V   z 

1) 

Jj 

us. 

^  u  on 

C/J 

>, 

co 

c    < 
13    2 
2    : 

chive 
i  les 
NGARCH" 

8.4 

S-4    Cm    < 

<          2 

T3 

\    C 

£ 

4->      0)     = 

s 

a) 

•H     Qj  E-t 

CO 

jj  >  = 

T3   a  h 

r-l                    >H 

^i  u  u 

Cd    <    Q     C\J 

03     Qj  CO 

.^, 

>i  -^    Cd 

\   Cd          • 

J    3  a 

3    U          ' 

nj  4-)  z 

0^3 

00 

11     U    Z    WJ 

-Q    0)    < 

O     03    U 

ct>  a>  < 

O      -t      2 

m  cq 

BllOS 

h   a)  = 

: 

£          - 

a  a 

2 

System  Management 

135 


t/1 

4-> 

-i    u 

0)     0 

4-1       <D 

O   cd 

ning 

Rpt  . 
EPT" 

3 

Trai 
Al low  . 
"TRALR 

9. 

Ge  ne  rate  Int. 
Reports 
"REPTMENU " 

9.0 

Print  Outstand- 
ing Req .  Rp t . 
"OSRQREPT" 

9.2 

Print 
Inventory  Rpt. 
"  INVREPT" 

9.1 

Generate  Internal  Reports 


136 


APPENDIX  E 
SAMS  PROGRAM  LISTINGS 


1.        AMSMAIN.PRG 

*AMSMAIN.PRG 

* 


First  Version  of  APIS  main  program 
Written  by  LT.  Steven  L.  Smith,  U 


USN  June  4,  1987 

clear  all 

set  talk  off 

set  status  off 

set  safety  off 

set  deleted  on 

set  confirm  off 

set  delimiters  on 

set  delimiters  to  "[]" 

clear 

@  4,10  to  10,70  double 

3  5,22  say  "      U.S.S.  Navy  Ship" 

@  3,22  say  "  Shipboard  Ammunition  Management  System" 

@  1,1  to  20,78  double 

@  12,27  say  "Today  is  "  +  cdow(date())  +  " ,  "  +  cmonth(date( ))  + 
lf  "  +  str(day(date()),2)  +  '',  "  +  str  (year(date( ) )  ,4) 

@  13,  10  say  "Author:  LT.  Steven  L.  Smith,  USN  " 

@  22,  10  say  "  Press  any  key  to  display  the  Main  Menu  " 
wait  "  " 

do  while  .T. 
clear 
text 

SAMS  MAIN  MENU 

1.  General  Information/Documentation 

2.  Inventory/Ammunition/Allowance  Data 

3.  Transaction  Management 

4.  Requisition  Management 

5.  Turn-in  Document  Management 

6.  NARS  Management 

7.  System  Management 

8.  Generate  Internal  Reports 

88.  Exit  to  dBase  III  Plus  Command  Level 
99.  Exit  to  MS-DOS  Operating  System 

endtext 

@  1,0  to  24,79  double 
@  3,1  to  3,78 
@  18,1  to  18,78 

store  0  to  MSELECT 

@  19,22  say  "  Enter  your  selection:  "  get  MSELECT  picture  "99" 

read 

do  case 

case  MSELECT  =  1 

do  INFOMENU 
case  MSELECT  =  2 

do  IMVMENU 
case  MSELECT  =  3 

do  TRANMENU 
case  MSELECT  =  4 

137 


do  REQMENU 
case  MSELECT  =5 

do  TURNMENU 
case  MSELECT  =  6 

do  NARSMENU 
case  MSELECT  =  7 

do  MANGMENU 
case  MSELECT  =  8 

do  REPTMENU 
case  MSELECT  =  88 

clear 

set  talk  on 

set  status  on 

set  safety  on 

set  deleted  off 

return 
case  MSELECT  =  99 

clear 

quit 
otherwise 

@  22,16   say   "Not   a  valid  selection--" 

@  23,16   say   "Press   any  key   to   try  again." 

wait   "    " 

endcase 


enddo      f.T.] 
clear   all 
return 


2.       BCKUPREQ.PRG 

*  BCKUPREQ.PRG 

*  This  program  backs  up  the  requisition  file  to  another  storage 

*  device  for  system  protection. 

*  Written  by  LT.  Steven  L.  Smith,  USN  1  Sept.,  1987 

clear 

@  5,15  say  "Requisition  File  Backup" 

text 

This  selection  will  copy  the  current  up-to-date  contents 
of  the  Requisition  File  to  your  backup  floppy  disk.  It  is 
important  to  do  this  after  each  session  in  which  you  change 
the  contents  of  the  file,  just  in  case  something  catastrophic 
happens  to  the  hard  disk. 

endtext 

@  18,5  say  "Place  the  backup  floppy  disk  with  the  Requisition" 
@  19,5  say  "File  on  it  in  drive  h-.n 

store  "  "  to  MCONFIRM 

@  22,10  say  "Are  you  ready  to  backup  the  file?  (Y/N)"; 

get  MCONFIRM  picture  "!" 

read 

if  MCONFIRM  =  "Y" 

run  BACKUP  AMREQUIS.dbf  A: 

*  run  BACKUP  AMREQUIS.dbf  A: /A 

wait  "Backup  Complete  -  Press  any  key  to  return" 

else 

return 
endif 

return 
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3.       COMPLREQ.PRG 

*  COMPLREQ.PRG 

*  Program  to  view  detailed  requisition  data 

*  Written  by  LT.  Steven  L.  Smith,  USN  15  June,  1987 

clear 
clear  all 

do  while  .T. 

@  1,  10  to  3,  60  double 

@  2,  15  say  "View  Complete  Requisition  Data" 

-> 
text 

1.  Specific  Requisition  (*  must  know  serial  number  *) 

2.  All  Requisitions  (*  newest  to  oldest  *) 

3.  QUIT 

endtext 

@  0,0  to  24,78  double 

store  "  "  to  CHOICE 

@  18,  15  say  "Enter  choice:  "  get  CHOICE  picture  "!" 
read 

do  case 

case  CHOICE  =  "1" 
clear 

store  0  to  SELECTION 

@  10,10  say  "Enter  the  requisition  serial  number:"; 
get  SELECTION  picture  "9999"  range  8000,8999 
read 
select  D 

use  AMREQUIS  index  AMRSERUP,AMRSERDW 
seek  SELECTION 

if  found() 
clear 
exit 
else 

@  14,10  say  "That  serial  number  is  not  in  the  file:" 

wait 
clear 
endif 

case  CHOICE  =  "2" 
select  D 

use  AMREQUIS  index  AMRSERUP,AMRSERDW 

goto  bottom 

clear 

exit 

case  CHOICE  =  "3" 
clear 

close  databases 
return 

otherwise 

@  14,10  say  "Not  a  valid  selection-" 

@  15,10  say  "Press  any  key  to  try  again" 

wait  "  " 

clear 

endcase 

enddo 

select  C 

use  AMMODATA  index  AMANIIN 

select  D 

do  while  .not.  bof() 

set  relation  to  NUN  into  AMMODATA 
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store  C->NALC  to  AMARK 
store  C->SHORTTITLE  to  BMARK 
store  C->UNITOFISSU  to  CMARK 
store  C->COGSYMBOL  to  DMARK 

set  relation  to 

store  SENDTOUIC  to  EMARK 
store  SUPADDUIC  to  FMARK 

use  AMDADDR  index  AMDUIC 
goto  top 
seek  EMARK 

if  found() 

store  ACTIVNAME  to  GMARK 
store  LOCATION  to  HMARK 

else 

store  "  "  to  GMARK 

store  "  "  to  HMARK 

endif 

goto  top 
seek  FMARK 

if  found() 

store  ACTIVMAME  to  IMARK 
store  LOCATION  to  JMARK 

else 

store  "  "  to  IMARK 

store  "  "  to  JMARK 

endif 

select  A 

use  AMSTDATA 

goto  top 

store  SERVCODE  to  KMARK 

store  UIC  to  LMARK 

select  D 

@  2,5  say  "Document  Number:  "  +KMARK+LMARK+"  "+; 
(ltrim(str(SERIAL)))+"  "+  JULIANDATE 

@  4,  5  say  "NALC:  "+AMARK 
@  4,  20  say  "NUN:  "+NIIN 
@  4,  40  say  "Short  title:  "+BMARK 

@  6,  5  say  "Quantity:  "+QUANTITY 
@  6,  25  say  "Unit-of-issue :  "+CMARK 
@  6,  48  say  "COG  Symbol:  "+DMARK 

@  8,  5  say  "Send  to:  "+SENDTOSERC+SENDTOUIC+" ,  "  +  ; 
rtrim(GMARK)+",  "+  rtrim(HMARK) 

@  10,  5  say  "Supplemental  Address:  "+SUPADDSERC+SUPADDUIC+; 

",  "+  rtrim(IMARK)  +" ,  "+  rtrim(JMARK) 

@  12,  5  say  "Project  Code:  "+PR0JC0DE 

(§12,  25  say  "Doc.  Ident.:  "+DOCIDENTIF 

@  12,  47  say  "Media/Status  Code:  "+MEDIASTAT 

@  14,  5  say  "Signal  Code:  "+SIGNALCODE 
@  14,  24  say  "Demand  Code:  "+DEMANDCODE 
0  14,  45  say  "Advice  Code:  "+ADVICECODE 

@  16,  5  say  "Priority  Code:  "+PRIORITYCD 

@  16,  32  say  "Required  Delivery  Date:  "+REQDELDATE 

@  19,  45  say  "Requisition  Status:  "+REQUISSTAT 
@  18,  43  to  20,  68 

skip-1 

if  CHOICE  =  "1" 

(§  22,  5  say  "Press  any  key  to  return" 
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wait  "  " 
close  databases 
return 
endif 

if  bof() 

(§22,  50  say  "End  of  File" 
endif 

do  while  .T. 

store  "  "  to  MCHOICE 

@  22,5  say  " (C)Continue ,  (R)Repeat,  (X)Exit  "; 
get  MCHOICE  picture  "I1' 
read 
do  case 

case  MCHOICE  =  "C"  .OR.  MCHOICE  =  "R" 

if  bof() 

goto  bottom 

clear 

exit 

else 

clear 
exit 

endif 

case  MCHOICE  =  "X" 
clear 

close  databases 
return 

otherwise 


@  23,  20  say  "Not  a  valid  selection,  press  any  key:" 
wait  "  " 
@  23,  1  clear 
@  24,  1  clear 


endcase 

enddo 

enddo 

close  databases 

return 


4.        CRENEWREQ.PRG 

*  CRENEWRQ.PRG 

x  Program  to  create  a  new  requisition 

*  Written  by  LT.  Steven  L.  Smith,  USN  8  June,  1987 

clear 

set  bell  off 

clear  all 

use  AMREQUIS  index  AMRSERDW,AMRSERUP,AMRREQDD 

5  2,15  say  "  CREATING  A  NEW  REQUISITION" 

@  1,10  to  3,47  double 

? 

? 

text 

Requisitions  require  some  coded  information  that  is  very 
difficult  to  remember.  Each  screen  in  this  subprogram  will 
ask  you  for  information  and  offer  a  description  of  the 
information  and  the  choices  available  to  you.  Some  items 
are  mandatory  on  a  requisition,  and  the  screen  will  tell 
you  so,  but  it  will  not  prevent  you  from  leaving  the  item 
blank.  It  is  important  then  that  you  check  to  make  sure  the 
requisition  is  complete  before  submitting  it. 

endtext 
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? 
•? 

wait  "       Press  any  key  to  start  entering  data" 

@  5,0  clear 

*****************  Serial  Number  Decision  **************** 

goto  top 

store  1  to  COUNT 

if  (  COUNT  +  SERIAL  )  =  9000 
text 

NOTE:  The  requisition  serial  numbers  have  reached 
8999  and  should  be  restarted  at  8000  IAW 
SPCCINST  8010. 12D.  You'll  have  the 
opportunity  to  do  that  by  continuing. 

endtext 

@  6,5  to  12,70   double 
wait 
clear 
endif 

do  while  .T. 

@  0,0  clear  to  5,50 

(?  2,15  say  "Requisition  Serial  Number  " 

@  1,10  to  3,47  double 

store  "  "  to  CHOICE 

store  0  to  VSERIAL 

@  9,8  say  "The  next  sequential  requisition  serial  number  is :  "; 

+ltrim(str(COUNT  +  SERIAL)) 
@  10,8  say  "  Is  that  serial  number  O.K.?  (Y,N)"  get  CHOICE  ; 

picture  "@!" 

read 

if  CHOICE  =  "Y" 

VSERIAL  =  SERIAL  +  COUNT 
exit 

else 

if  CHOICE  =  "N" 
@  5,0  clear 
text 

WARNING:  A  non-sequential  serial  number  should  only 
be  used  when  you  reach  requisition  8999  and  need  to 
reset  the  numbers  back  to  8000  IAW  SPCCINST  8010. 12D. 
The  system  will  alert  you  when  this  happens.  A  serial 
number  less  than  the  one  reported  above  could  be  a 
duplicate;  the  system  also  attempts  to  check  for 
this. 

endtext 

@  6,5  to  15,75  double 

do  while  .T. 

store  "  "  to  MCHOICE 

@  17,6  say  "Do  you  still  wish  to  choose  a  serial"; 

+"  number  other  than  "  +  ltrim(str(COUNT  +  SERIAL)); 

+",(Y/N)?"; 

get  MCHOICE  picture  "@!" 

read 

if  MCHOICE  =  "N" 

clear 

exit 
endif 

if  MCHOICE  <>  "Y"  .AND.  MCHOICE  <>  "N" 

@  22,8  say  "That  is  not  a  valid  response--  " 
@  23,8  say  "Press  any  key  to  try  again:  " 
wait  "  " 
clear 
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endif 

if  MCHOICE  =  "Y"    .  ' 
do  while  .T. 
store  0  to  VSERIAL 

@  22,8  say  "Enter  the  requisition  number:1 
get  VSERIAL  picture  "9999"  range  8000,; 
8999 
read 

set  index  to  amrserup,amrserdw,amrreqdd 

seek  VSERIAL 

if  found() 

(§5,0  clear 
@  16,20  say  "That  is  a  duplicate  serial  number-' 
@  17,20  say  "  Press  any  key  to  try  again:" 
wait"  " 
else 

exit 
endif 


enddo 


endif 
enddo 


if  MCHOICE  =  "Y" 

exit 
endif 


else 


if  CHOICE  <>  "Y"  .AND.  CHOICE  <>  "N" 

@  12,8  say  "That  is  not  a  valid  response--" 
@  13,3  sav  "Press  any  key  to  try  again  " 
wait  "  " 
clear 
endif 
endif 
endif 

if  MCHOICE  =  "Y" 
exit 
endif 

enddo 

close  databases 
kkkkkkkkkkkkkkkkkkk   End  "™  Serial  Number  Decision  ************* 

kk^kkkkkkkirkkkkkkkkk    Enter  NUN  ************************** 

clear 

store  "         "  to  VNIIN 

@  5,10  say  "National  Item  Identification  Number  --NIIN" 

@  4,5  to  6,70  double 

do  while  .T. 

store  "  "  to  CHOICE 


ly  "Do  you  know  the  NUN  of  the  item  you  wish 
ly  "order? (Y/N) :"  get  CHOICE  picture  ft!" 


@  3,  15  say  "Do  you  know  the  NUN  of  the  item  you  wish  to" 

@  9,  15  sa} 

read 


do  case 

case  CHOICE  =  "N" 
? 

text 

Go  to  the  Inventory  Management  program  from  the  main 
menu  and  find  the  NUN  or  the  item  you  wish  to  order. 

If  this  is  a  new  item  not  yet  in  the  database,  be 
sure  to  add  it.  Contact  the  SAMS  coordinator  or 
Weapons  Officer  if  you  do  not  have  the  access  to 

do  this, 
endtext 

wait 
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clear 

close  databases 

return  to  master 

case  CHOICE  =  "Y" 

@  11,  10  say  "Enter  the  NUN  (leave  out  the  blanks)"; 

get  VNIIN  picture  "@!" 
read 

use  AMMODATA  index  AMANIIN,  AMANALC 
seek  VNIIN 

if  found() 

do  while  .T. 

store  "  "  to  MCHOICE 

@  13,  5  say  "That  NUN  is  for:  " 

set  heading  on 

display  NIiN,NALC,SHORTTITLE 

@  18,  5  say  "Is  this  the  correct  item?(Y/N)  " ; 

get  MCHOICE  picture  " ! " 
read 

do  case 

case  MCHOICE  =  "Y" 
@  7,  0  clear 
exit 

case  MCHOICE  =  "N" 
•> 

text 
Go  to  the  Inventory  Management  program 
from  the  main  menu  to  verify  the  NIIN. 

endtext 

wait 

clear 

close  databases 

return  to  master 

otherwise 
@  20,  10  say  "That  is  not  a  valid  response 
@  21,  10  say  "Press  any  key  to  try  again-" 
wait 
@  7,  0  clear 


enddo 


endcase 


if  MCHOICE  =  "Y1 

exit 
endif 


else 


(§15,  10  say  "That  NIIN  is  not  in  the  General" 
d  16,  10  say  "  Ammunition  Information  file." 

text 

Go  to  the  Inventory  Management  program  from  the 

main  menu  and  verify  that  NIIN. 
endtext 
■> 

wait 

clear 

close  databases 

return  to  master 


endif 
otherwise 


@  10,  10  say  "That  is  not  a  valid  response--" 
d  11,  10  say  "Press  any  key  to  try  again:  " 


wait 
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@  7,  0  clear 
endcase 

enddo 

use  AMREQUIS  index  AMRSERUP,AMRSERDW,AMRREQDD 

aopend  blank 

replace  SERIAL  with  VSERIAL,  NUN  with  VNIIN 

@7,  0  clear 

@  10,  10  say  "Requisition  serial  number  "  +  str(SERIAL) 

£11,  10  say  "created  for  NUN  "  +  NUN 

wait 

kkkkkkkkkkkkkkkkk    £n£  NUJJ  Decision  ********************** 
kkkkkkkkkkkkkkkkkkk    QUANTITY  ********************** 

close  databases 

clear 

§  1,  10  to  3,  SO  double 

@  2,  25  say  "Quantity" 

use  AMMODATA  index  AKANIIN 
seek  VNIIN 

@  5,  10  say  "  The  unit-of-issue  for  NUN  "  +  NUN  +  ",  "; 

+  SKORTTITLE  +  "is:  "  +  UNITOFISSU 

use 

use  AMREQUIS  index  AMRSERUP, ANRSERDW, ANRREQDD 

seek  VSERIAL 

store  "     "  to  VQUANITY 


7 
7 

text 


endtext 


The  quantity  must  be  given  as  five  digits.  So  if  your 
quantity  is  less  than  that,  fill  in  the  positions  to  the 
left  with  zeros.  (Example:  quantity  325  would  be  given  as 
00325,  5  would  be  given  as  00005.  If  you  are  ordering  more 
than  99999,  use  an  "M"  in  the  rightmost  position  for 
thousands  and  adjust  the  other  numbers  acccordingly. 
Ref:  SPCCINST  3010. 12D  Para  8-208f. 


@  22,  15  say  "Enter  the  quantity  you  desire:  "  get  VQUANITY; 
picture  ^' !  !  !  !  !  " 
read 

replace  QUANTITY  with  VQUANITY 

k-kk-kkkkkkkkk-kkkkkkkkk    £nd    OuantitV    Decision     ****** ********* 
kkkkkkkkkkkkkkk-k-kk-kkk Jq]_  i  gfj    Date     ******************** 

clear 

@  1,  10  to  3,50  double 

5  2,  23  say  "Julian  Date" 

text 

NOTE:  The  4  digit  Julian  date  on  a  requisition  that  will  be 
transmitted  by  electronic  media  (radio)  must  be 
equivalent  to  the  date- time-group  on  the  message,  so 
ir  your  radio  room  or  communications  center  can  not 
transmit  the  message  on  the  day  you  think  they  will, 
it  might  be  best  to  leave  the  date  blank  below  (  by 
just  pressing  <RETURN>).  Or  you  could  put  the  date  in 
and  change  it  later. 

On  a  manual  requisition,  DD  form  1348,  this 
requirement  does  not  exist,  so  just  put  down  the  date 
you  expect  to  turn  in  the  requisition. 

Julian  Date  Format:  (YDDD) 
Y  -  last  digit  of  current  year  (ex.  1987  -  7  ) 
DDD  -  Julian  day  of  year  (  use  3M  calendar  ) 

Ref:  SPCCINST  8010. 12D  Para  8-208g(3) 
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endtext 
•> 

store  "    "  to  VDATE 

@  22,  15  say  "Enter  the  Julian  Date  or  press  <RETURN>:  " ; 

get  VDATE  picture  "XXXX" 

read 

replace  JULIANDATE  with  VDATE 

kkkkkkkkkkkkkkfc^fi    Julian  Date  Decision  *******  ********* 

****************  Requisition  and  Loadout  Point  ********* 

clear 

§  1,  10  to  3,  60  double 

@  2,  15  say  "Requisition  Routing  and  Loadout  Point" 
■? 

■> 

text 

Naval  message  requisitions  always  go  to  SPCC  Mechanicsburg, 
PA.,  N00104.  Requisitions  sent  via  DAAS  format  always  go  to 
DAAS  (Defense  Automated  Addressing  System),  Dayton,  OH. 

(Ref.  SPCCINST  8010. 12D) 
However,  fleet  instructions  vary  on  who  should  receive 
requisitions  if  submitted  by  message(DAAS  incl).  Therefore  you 
should  indicate  below  who  will  receive  the  requisition  or  be 
the  primary  action  addee  on  a  message.  This  is  necessary  to 
assign  the  proper  routing  identification  code. 

The  supplemental  address  is  the  location  where  you  plan  to 
actually  receive  the  material  and  load  it  out.  you  need  to 
fill  this  in  so  that  the  supply  system  will  know  where  to 
send  the  material  and  from  which  supply  point  to  fill  the 
order. 

The  next  screen  will  show  you  the  most  common  supply 
activities  and  vessels  in  your  area  (  and  beyond  ; . 
A  complete  list  is  in  NAVSUP  Pub.  485,  App.  7. 

endtext 

wait 

@  4,0  clear 

close  database 

use  AMDADDR  index  AMDUIC 
store  "  "  to  VSERVCOD 
store  "     "  to  VUIC 
store  "  "  to  VSUPSRCD 
store  "     "  to  VSUPUIC 

goto  top 

do  while  .not.  eof() 

List  next  6  SERVCODE,UIC,ACTIVNAME, LOCATION 
if  eofQ 

@  17,10  say  "That's  all  the  activities  on  file." 
endif 

@  18,5  say  "Enter  service  code  of  requisition  recepient :" ; 

get  VSERVCOD  picture  "1" 

read 
@  19,5  say  "Enter  the  UIC  of  requisition  recepient:"; 

get  VUIC  picture  ^XXXXX" 

read 
@  20,5  say  "Enter  service  code  of  supplemental  address:  "; 

get  VSUPSRCD  picture  ,r! " 

read 
@  21,5  say  "Enter  UIC  of  supplemental  address:  "; 

get  VSUPUIC  picture  "XXXXX" 

read 

do  while  .T. 

store  "  "  to  CHOICE 

@  22,5  say  "Want  to  see  more  locations  or  review  again? (Y/N)" ; 

get  CHOICE  picture  "!" 
read 
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do  case 

case  CHOICE  =  "N"  - 
exit 

case  CHOICE  <>  "N"  .AND.  CHOICE  <>  "Y" 

@  23,5  say  "Not  a  valid  choice,  press  any  key.-" 
wait  "  " 
@  23,1  clear  to  23,70 

case  CHOICE  =  "Y" 
@  4,  0  clear 
exit 
endcase 

enddo 

if  CHOICE  =  "N" 

exit 
endif 

if  CHOICE  =  "Y"  .AND.  eof() 
goto  top 
@  4,  0  clear 
endif 

enddo 

use 

use  AMREQUIS  index  AMRSERUP, AMRSERDW, AMRREQDD 

seek  '/SERIAL 

replace  SENDTCSERC  with  VSERVCOD,  SENDTOUIC  with  VUIC,; 

SUPADDSERC  with  VSUPSRCD,  SUPADDUIC  with  VSUPUIC 
*********x***£ncj  Requisition  Routing/Loadout  Point****** 

bTt-k-k-k-x-k-k-kTr-k-k-k-x-k-k-k-kk-k    Project  Codes  ******************** 

clear 

3  1,  10  to  3,  60  double 

@  2,  15  say  "         Project  Code   " 

■> 

text 

Project  Codes  basically  tell  what  you  are  requisitioning  the 
ammunition  for.  The  most  common  codes  for  fleet  units  are 
shown  below,  and  more  complete  lists  can  be  found  in  SPCCINST 
3010. 12D,  NAVSUP  Pub  485  App.  6,  and  in  the  System 
Documentation  section  of  this  program. 

endtext 

■> 

■> 

wait"  Press  any  key  to  show  project  codes:" 
@  4,  0  clear 

do  while  .T. 
text 

Code  Project  Title 

835      Ammunition  requisitioned  for  the  replacement  of 

service  ammunition  that  was  used  during  annual  or 
fleet  exercise  training. 

337       Load  adjust(shipfill)-  Onload/offload  of  shipfill 

ordnance  to/from  combatants  or  MLSF  to  facilitate 
offload/onload  of  training  ordnance. 

876  Training.  Ammunition  requisitioned  for  or  turned  in 

following  annual  training  or  fleet  exercise. 

877  Ship  Loadout.  Ammunition  requisitioned  to  fill  ship 

service  allowance  for  ship  deployment. 

373       Ammunition  Exchange.  Ammunition  requisitioned  and/or 
turned  in  for  exchange  due  to  NAR's,  overage 
components,  obsolescence,  etc. 
endtext 
wait 

5  4,  0  clear 
text 
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Code  Project  Title 

390      New  Construction.  Initial  onload(reqn. )  of 

ammunition  for  newly  constructed  or  activated  ships. 

891       Ship  Overhaul.  Down  load( turn-in)  of  ammunition 
prior  to  entering  yard  for  overhaul  and  onload 
(reqn.)  of  such  ammunition  upon  leaving  the  yard. 

392       Ships  Restricted  Availability.  Ammunition  off-loaded 
(turned- in)  required  by  entering  a  restricted 
availability  period  and  the  subsequent  onload(reqn. ) 
of  ammunition  upon  completion. 

endtext 

wait 

@  4,  0  clear 

do  while  .T. 

store  "  "  to  CHOICE 

@  15,10  say  "Do  you  need  to  review  the  codes  again? (Y/N)" ; 
get  CHOICE  picture  " ! " 
read 
do  case 

case  CHOICE  =  "N" 

exit 

case  CHOICE  =  "Y" 

exit 

case  CHOICE  <>  "N"  .AND.  CHOICE  <>  "Y" 

@  17,10  say  "Not  a  valid  choice,  try  again:" 

wait 

@  17,1  clear  to  17,  70 

@  18,1  clear  to  18,  70 

endcase 
enddo 

if  CHOICE  =  "N" 

exit 
endif 
(§4,0  clear 
enddo 

store  "    "  to  VPROJCOD 

@  20,  10  say  "Enter  the  appropriate  project  code:  " ; 

get  VPROJCOD  picture  "!!!" 

read 

replace  PROJCODE  with  VPROJCOD 

kkkkkkkkkkkkkkkkkk   g^d  Proiect  Code  Decision  ************ 
■kkkkkkkkkkkkkkkkkkk   Document  Identifier  ***************** 
clear 
@  1,10  to  3,  50  double 

d  2,  15  say  "  Document  Identifier" 
7 

7 

text 

The  document  identifier  identifies  the  purpose  of  the 
document  rapidly  to  the  data  entry  personnel  at  the  supply 
activities  and  can  be  recognized  by  automated  machinery  which 
processes  many  supply  documents  these  days.  By  purpose  it  is 
meant  requisition,  issue,  status,  cancellation,  etc.. 
More  information  and  complete  lists  of  document  identifiers 
are  contained  in:  SPCCINST  8010. 12D  Para.  8-208  2(a)  and 
NAVSUP  Pub  485  App.  4.      (*  MANDATORY  ITEM  *) 

endtext 

7 

7 

wait"  Press  any  key  to  view  choices  and  make  selection:" 

0  4,  0  clear 
7 

text 

Doc.  Iden.  Meaning 

A01  For  delivery  outside  CONUS  with  NSN 
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A04  For  delivery  outside  CONUS  with  NALC-NIIN 

AOA  For  delivery  within  CONUS  with  NSN 

AOD  For  delivery  within  CONUS  with  NALC-NIIN 

*  A05  For  delivery  outside  CONUS  w/exception  data 

*  AOE  For  delivery  inside  CONUS  w/exception  data 

*  --  Can't  be  used  for  DAAS    NSN  =  FSC  +  NUN 
er.dtext 

■> 

store  :1   "  to  VDOCIDEN 

i?  22,  10  say  "  Enter  the  appropriate  document  identifier:  "  ; 

get  VDOCIDEN  picture  "I!!" 

read 

replace  DOCIDENTIF  with  VDOCIDEN 
K^it-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k   End  -  document  Identifier  ************ 

kkkkkkkkkkkkkkkkkkkkk    Media  and  StatUS  Code  ***************** 

c  lear 

@  1,  10  to  3,60  double 

@  2,i5  say  "  Media  and  Status  Codes  " 

? 

text 

The  Media  and  Status  Code  is  used  by  the  supply  system  to 
determine  what  type  of  status  should  be  given  regarding  the 
processing  of  the  requisition;  who  should  receive  this  status 
and  by  what  kind  of  communications  transmission  this  status 
should  come.  Complete  information  on  this  code  is  contained 
in  NAVSUP  Pub  485  App.  16.   (*  MANDATORY  *) 

endtext 

p 

•> 

wait"  Press  any  key  to  show  more  amplifying  information:" 

@  4,  0  clear 

do  while  .T. 
text 

Definitions : 

(a)  EXCEPTION  STATUS  will  be  used  to  request  information 
relative  to  any  action  taken  by  the  supply  source  other 
than  issue  of  the  material. 

(b)  100%  SUPPLY  STATUS  will  be  used  to  request  information 
relative  to  any  action  taken  by  the  supply  suorce 
including  release  of  material  for  shipment,  but  not 
including  bill  of  lading  numbers  or  mode  of  shipment. 

(c)  SHIPMENT  STATUS  may  be  used  in  conjunction  with 
exception  status  or  100%  supply  status  to  request  positive 
information  of  shipment,  including  date  of  shipment,  mode, 
bill  of  lading,  or  airway  bill  number,  as  applicable. 

Supply  status  for  ammunition  requisitions  will  be  provided 
to  both  the  requisitioner  and  the  supplemental  addressee, 

?rovided  one  is  given. 

•> 

wait"  Press  any  key  to  view  choices:  " 

@  4,  0  clear 
text 

M&S  Code  Definition 

0  No  status  provided 

2  Provide  exception  status  via  AUTODIN 

3  Provide  exception  status  by  mail 

*  B  Provide  100%  supply  and  exception  status 

by  AUTODIN 
C  Provide  100%  supply  and  exception  status 

by  mail 

149 


*  K  Provide  exception  and  shipment  status 

by  AUTODIN   .  " 
L  Provide  exception  and  shipment  status 

by  mail 
M  Provide  exception  and  shipment  status 

by  message 

*  S  Provide  100%  supply  and  shipment  status 

by  AUTODIN 

*  T  Provide  100%  supply  and  shipment  status 

by  mail 
*  --  Required  for  priorities  01  -  08 
endtext 
wait 
@  4,  0  clear 

do  while  .T. 

store  "  "  to  CHOICE 
@  6,  10  say  "Do  you  need  to  see  the  definitions  again? (Y/N) " • 
get  CHOICE  picture  "!" 
read 

do  case 

case  CHOICE  =  "Y" 

@  4,  0  clear 

exit 
case  CHOICE  =  "N" 

exit 
case  CHOICE  <>  "N"  .AND.  CHOICE  <>  "Y" 

@  10,10  say  "Not  a  valid  choice:" 

wait 

@  10,5  clear  to  10,70 

@  11,0  clear  to  11,70 
endcase 


enddo 


enddo 


if  CHOICE  =  "N" 
exit 

endif 


store  "  "  to  VMEDSTAT 

@  15,  10  say  "  Enter  the  appropriate  M&S  Code:  " ; 

get  VMEDSTAT  picture  "!" 

read 

replace  MEDIASTAT  with  VMEDSTAT 
*******************   £nci  Media  and  Status  Code  Decision  **** 
*******************   Demand  Code  ************************ 
clear 

@  1,  10  to  3,50  double 
@  2,15  say  "'    Demand  Code   " 

text 

At  last  a  simple  code! 

R  -  Recurring  demands.  Use  when  item  requisitioned 
is  for  shipfill  ammunition. 

N  -  Non-recurring  demands.  Use  when  item 

requisitioned  is  clearly  a  "one-time"  request, 
or  is  the  initial  loadout  of  the  ship  when 
commissioned. 

Ref:  NAVSUP  Pub  435  sec.  3023,  3024 
endtext 

■? 

•> 

store  "  "  to  VDEMCOD 

@  20,10  say  "  Enter  the  appropriate  letter:  " ; 

get  VDEMCOD  picture  "!" 

read 

replace  DENANDCODE  with  VDEMCOD 
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******************  gncj  Demand  Code  ************************** 

*********** ******   signal  Code  ************************ 

clear 

@  1,10  to  3,50  double 

@  2,15  say  "    Signal  Code" 

•? 
text 

The  signal  code  is  used  to  identify  the  activity  to  which  the 

material  is  to  be  shipped  and/or  billed. 

Ref:  NAVSUP  Pub  485  App  14     (*  MANDATORY  *) 

Signal  Code  Meaning 

A  Ship  and  bill  to  requisitioner 

B  Ship  to  requisitioner  and  bill  to 

supplemental  address 

J  Ship  to  supplemental  address  and  bill 

to  requisitioner.  Use  Signal  Code  J 
when  when  the  supplemental  address  is 
used  to  denote  the  loadout  activity. 

K  Ship  and  bill  to  supplemental  address 

endtext 

store  "  "  to  VSIGCOD 

@  22,  10  say  "  Enter  the  Signal  Code:  "  get  VSIGCOD  picture  "!" 

read 

replace  SIGNALCODE  with  VSIGCOD 
****************  £ftcj  Signal  Code  **************************** 

********************  priority  Code  (  Desionator)  ************ 

clear 

@  1,10  to  3,60  double 

@  2,15  say  "  Priority  Code  (Designator)  " 

text 

The  Priority  Code  (0-15)  expresses  the  relationship  between 
the  requisitioner ' s  assigned  force/activity  designator  and 
the  selected  urgency  of  need  designator,  and  determines  the 
time  frame  within  which  the  requisition  will  be  processed. 
Basically  it  determines  how  big  a  wig  you  are  and  how  fast 
they  have  to  fill  your  order!  if  you  don't  know  your  unit's 
assigned  force/activity  designator  check  with  the  Supply 
Officer.  The  chart  on  the  next  screen  will  help  you  determine 
your  priority  code.  Priority  Codes  are  fully  explained  in 
NAVSUP  Pub  435  sec.  3045-3049,  it  is  worth  reading  once.  Your 
unit  can  generally  only  use  3  of  the  Priority  Codes  since  you 
have  one  assigned  F/AD{Force/Activity  Designator). 

endtext 

wait  "  Press  any  key  to  see  the  PD  table:" 
@  4,  0  clear 

text 

Priority  Code  Table 

Urgency  of  Need  Designator | 


A  (Unable  to  perform) 
B  (Performance  Impaired) |  04 
C  (Routine  ) 
endtext 


Force/Activity  Designator 

I 

II 

III 

IV 

V 

01 

02 

03 

07 

08 

04 

05 

06 

09 

10 

11 

12 

13 

14 

15 
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store  "   "  to  VPRIRCOD 

@  20  ,  10  say  "Select  an  appropriate  priority  code:  " • 

get  VPRIRCOD  picture  "XX" 

read 

replace  PRIORITYCD  with  VPRIRCOD 

kkkkkkkkkkkkkkkkkk    £n(j  Priority  Code  ********************** 

kkkkkkkkkkkkkkkkkkkk^QQ-^2, red  Delivery  Date  (RDD)  ********** 

clear 

@  1,  10  to  3,  60  double 

@  2,  15  say  "  Required  Delivery  Date  (RDD)  " 

-> 

text 

The  RDD  is  the  date  that  you  require  the  material  onboard 
and/or  the  date  of  the  loadout.  It  is  the  3  digit  Julian 
day  of  the  year  (DDD).  They  figure  out  the  year  from  the 
rest  of  the  requisition!      (*  MANDATORY  *) 

endtext 

■? 

store  "    "  to  VJDATE 

@  20,  10  say  "  Enter  the  Required  Delivery  Date:  "  ,- 

get  VJDATE  picture  "XXX" 

read 

replace  REQDELDATE  with  VJDATE 
kkkkkkkkkkkkkkkkkkkkkkkkk^fifi   Required  Delivery  Date  ******* 

***********************  Advice  Codes  ******************** 

clear 

@  1,10  to  3,50  double 

@  2,15  say  "  Advice  Codes  " 

text 

An  advice  code  may  be  entered  on  the  requisition  to  provide 
the  supply  source  with  special  insrtuctions  to  ensure 
appropriate  supply  action  is  taken.  The  codes  listed  on 
the  next  screen  are  the  only  advice  codes  that  may  normally 
be  used  by  Navy  units  to  order  ammunition.  SPCCINST 
8010. 12D  lists  a  few  others  that  may  be  used  when 
authorized  by  higher  authority.  NAVSUP  Pub  485  App.  1  gives 
complete  information  on  Advice  Codes,  but  note  that  only 
those  listed  in  the  SPCC  inst.  may  be  used  for  ammunition. 
Advice  code  may  be  left  blank. 

endtext 

(§20,  10  say  "Press  any  key  to  view  choices--  " 

wait  "  " 

@  4,  0  clear 
text 

Code  Description 

2B  Do  not  substitute/interchange.  Requested 

item  only  will  suffice. 

2C  Do  not  back  order.  Reject  all  unfilled 

quantities  not  available  to  meet  RDD. 
Suitable  substitute  acceptable. 

2D  Furnish  exact  quantity  requested  (do  not 

adjust  to  unit  pack  quantity) 

2J  Do  not  substitute  or  backorder. 

2T  Deliver  to  the  requisitioner  by  the  RDD 

or  cancel  requirement, 
endtext 
■? 

store  "   "  to  VADVCOD 

@  22,  10  say  "  Enter  Advice  Code  (if  desired):  "  get  VADVCOD; 

picture  " ! ! " 
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read 
replace  ADVICECODE  with  VADVCOD 
A*******************  End  Advice  Code  ************************ 

■k-k-k-kx-k-k-k-kx-k-k-x-k-kls-k-k    RgQii''  S  i  tion  StatUS  ********************** 

clear 

?  0,10  to  2,55  double 

@  1,15  say  "  Requisition  Status  " 

text 

Requisition  Status  indicates  the  degree  to  which  a 
requisition  is  complete,  ready  for  submission,  submitted  but 
unfilled,  etc..  It  is  a  code  established  by  this  system 
(SAMS),  and  not  the  Navy  supply  system.  The  Navy  supply 
system  has  many  status  codes  or  its  own.  This  requisition 
status  is  for  your  use  in  managing  your  conventional 
ammunition  requisitions,  receipts,  etc..  It  will  be  used  in 
SAMS  in  various  ways. 

NOTE:  The  only  item  that  may  be  left  blank  on  a  requisition 
you  submit  is  the  Advice  Code.  Therefore  it  is  a  good 
habit  to  simply  assign  appropriate  values  to  all  items 
that  this  program  has  requested. 

The  next  couple  of  screens  will  show  you  all  the  selections 
that  you  have  made,  the  exact  meaning  of  the  status  codes, 
and  ask  you  to  assign  one.  All  the  values  shown  have  been 
written  to  the  file,  so  in  order  to  change  any  values  we'll 
finish  this  part  of  the  program  and  select  the  edit  option 
from  the  "Requisition  Management"  menu,  if  desired. 

endtext 

wait 

@  3,  0  clear 

@  4,10  say  "Requisition  Values  Assigned" 

@  7,  10  say  "Serial  Number  =  "  +  str(SERIAL) 

@  3,10  say  "NUN  =  "  +  NUN 

@  9,  10  say  "Quantity  =  "  +  QUANTITY 

@  10,  10  say  "Julian  Date  =  "   +  JULIANDATE 

@  11,10  say  'Send  to  service  code  =  "  +  SENDTOSERC 

@  12,10  say  "Send  to  UIC  =  "  +  SENDTOUIC 

@  13,10  say  "SupDlemental  address  service  code  =  "  +  SUPADDSERC 

@  14,10  say  "Supplemental  address  UIC  =  "  +  SUPADDUIC 

@  15,  10  say  "Project  Code  =  "  +  PROJCODE 

@  16,  10  say  "Document  Identifier  =  "  +  DOCIDENTIF 

@  17,10  say  "Media  and  Status  Code  =  "  +  MEDIASTAT 

(§13,  10  say  "Demand  Code  =  "  +  DEMANDCODE 

@  19,  10  say  "Signal  Code  =  "  +  SIGNALCODE 

@  20,  10  say  "Priority  Code  =  "  +  PRIORITYCD 

@  21,  10  say  "Required  Delivery  Date  =  "  +  REQDELDATE 

@  22,  10  say  "Advice  Code  =  "  +  ADVICECODE 

wait  "Press  any  key  to  see  codes  and  assign  one:  " 

@  3,  0  clear 

text 

Code  Meaning 

I  Incomplete.  Some  mandatory  fields  are  missing 

or  you  are  not  ready  submit  it. 

R  Ready.  Requisition  is  ready  for  submission. 

U  Unfilled.  Requisition  has  been  submitted  but 

is  unfilled. 

P  Partial.  Requisition  has  been  submitted  and  is 

partially  filled. 

F  Filled.  Requisition  fully  filled. 

C  Cancelled, 

endtext 

store  "   "  to  VREQSTAT 
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@  22,  10  say 


Enter  Requisition  Status  code: 
picture  "! ! !" 
read 


get  VREQSTAT; 


replace  REQUISSTAT  with  VREQSTAT 
wait'Tress  any  ke 


***************** 


y  key  to  return  to  Requisition  Manag 
*********     End  Requisition  Status  ** 


ement  menu:" 
*********** 


*********************   End  CRENEWRO.PRG  ***************** 
close  databases 
set  bell  on 
return 


5.        DATAELEM.PRG 


*  DATAELEM.PRG 

*  This  program  allows  the  user  to  review  the  Data  Element 

*  Dictionary  and  print  it  if  desired. 

*  Written  by  LT.  Steven  L.  Smith,  USN  31  July,  1987 

*  Activate  next  two  items  if  program  used  alone, 
set  talk  off 

set  status  off 
set  bell  off 

do  while  .T. 

clear 

(§5,15  say  "SAMS  Data  Element  Dictionary" 

@  4,10  to  6,48 

•? 


text 


What  would  you  like  to  do? 

1.  Review  the  Data  Element  Dictionary 

2.  Print  the  Data  Element  Dictionary 

3.  Quit 


endtext 

store  0  to  GITEM 
@  20,10  say  "Enter  Choice 
read 


get  GITEM  picture  "9"  range  1,3 


do  case 

case  GITEM  =  1 

@  7,0  clear 

use  DATAELEM  index  DATANAME 

do  while  .T. 

@  8,2  say  "DEN: 

@  9,2  say  "NAME: 

@  10,2  say  "LONG  TITLE: 


"+DEN 

"+NAME 

"+L0NGTITLE 

"♦PICTURE 

"+trim(DESCRIPTIO) 

"+trim(S0URCE_FIL) 

"+trim(REFERENCE) 


@  11,2  say  "PIC: 
@  12,2  say  "DESC: 
@  18,2  say  "USED  IN: 
@  19,2  say  "REFS: 

skip 

if  eof() 

@  23,60  say  "End  of  File" 
endif 

do  while  .T. 

store  "  "  to  XCH 

@  22,5  say  " (C)Continue  (R)Repeat  (X)Exit 

get  XCH  picture  ' 

read 


n  i  M 


do  case 

case  XCH  =  "C 


OR.  XCH  =  "R' 
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if  eof() 

goto  top 
endif 

@  7,0  clear 
exit 

case  XCH  =  "X" 
use 
@  7,0  clear 

exit 

otherwise 
@  23,5  say  "Invalid  selection,  Press  a  key-- 
wait"  " 
@  22,0  clear 
endcase 
enddo 

if  XCH  =  "X" 

exit 
endif 


enddo 


case  GITEM  =  2 

clear 
@  10,10  say  "Ensure  printer  is  on,  and  press  a  key  to  start:" 

wait"  " 

clear 

@  12,20  say  "Printing,  do  not  disturb" 

@  11,15  to  13.50  double 

use  DATAELEM  index  DATANAME 

set  device  to  print 

@  1,10  say  "SAMS  Data  Element  Dictionary"+chr(10) 

@  prow(),0  say  "  

"+chr(10) 

5  prow( ) ,0  say  " 


_"+chr(10) 
do  while  .NOT.  eof() 


"+DEN+chr(10) 
"+NAME+chr(10) 
,2  say  "LONG  TITLE:  "+(LONGTITLE) ; 


@  prow()+2,2  say  "DEN: 

d  prow(),2  say  f'NAME : 

@  prow( 

+chr(10 

@  prow() ,2  say  "PIC: 

@  prow() ,2   say  "DESC: 

+chr(10) 

@  prow()+6,2  say  "USED  IN 

+chr(10) 

@  prow() ,2  say  "REFS: 

+chr(10 


@  prow(),0  say  " 

"+chr(10) 


"+PICTURE  +chr(10) 
"+trim(DESCRIPTIO) ; 

"+trim(SOURCE_FIL) ; 

"+trim(REFERENCE); 


skip 
enddo 

use 

set  device  to  screen 


case  GITEM  =  3 

clear 

set  talk  on 

set  status  on 

set  bell  on 

return 

endcase 


enddo 
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return 


6.        EDITREQ.PRG 

*  EDITREQ.PRG 

*  This  program  allows  editing  and  deleting  of  certain 

*  requisitions 

*  Written  by  LT.  Steven  L.  Smith,  USN  16  June,  1987 

do  while  .T. 
clear 
close  databases 

@  1,  10  to  3,  60  double 

@  2 ,  15  say  "Editing  and  Deleting  Requisitions" 
■p 

■> 

text 

What  would  you  like  to  do? 

1.  Edit  or  Change 

2.  Delete 

3.  Return  to  previous  menu 

NOTE:  For  obvious  reasons  you  can  only  delete  or  edit  a 
requisition  that  has  not  been  submitted.  Therefore  this 
program  will  check  to  make  sure  that  the  requisition 
you  select  has  a  status  code  of  (I)Incomplete  or 
{R)Ready. 
endtext 

store  0  to  CHOICE 

@  20,  20  say  "Enter  your  choice:  "  get  CHOICE  picture  "9"; 

range  1,3 

read 

if  CHOICE  =  3 
return 

else 

@  4,  0  clear 

store  0  to  NUMBER 

@  8,  10  say  "What  is  the  serial  number  of  the" 

@  9,  10  say  "requisition  that  you  want  to  edit" 

@  10,10  say  "or  delete?"  get  NUMBER  picture  "9999"; 

range  8000,8999 
read 

se lee t  A 

use  AMREQUIS  index  AMRSERUP,AMRSERDW,AMRREQDD 

use  AMMODATA  index  AMANIIN 
sslsct  A 
set  relation  to  NUN  into  AMMODATA 

seek  NUMBER 

if  found() 

@  12,10  say  "Requisition  "  +  ltrim(str(NUMBER) )  +  "  is  for-." 
@  13,10  say  B->SHORTTITLE 

@  14,10  say   "  NALC:  "+B->NALC+n    NUN:  "+NIIN+"   QUANTITY:  "  ; 
+QUANTITY 

do  while  .T. 

store  "  "  to  MCHOICE 
@  16,15  say  "Is  this  the  correct  item?(Y/N)" ; 
get  MCHOICE  picture  "!" 
read 

do  case 
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case  MCHOICE  =  "Y" 
exit 

case  MCHOICE  =  "N" 

@  18,15  say  "Return  to  Requisition  Management  main" 

@  19,15  say  "menu  and  check  serial  number  with" 

@  20,15  say  "option  1  or  2." 
? 

wait 

clear 

close  databases 

return 

otherwise 

@  18,15  say  "Not  valid  selection,  press  " 
@  19,15  say  "any  key  to  try  again:1' 

wait'^  " 

@  16,0  clear 

endcase 

enddo 

if  REQUISSTAT  <>  "I"  .AND.  REQUISSTAT  <>  "R" ; 
.AND.  REQUISSTAT  <>  "  " 
@  13,15  say  "That  item  may  not  be  edited  or  " 
@  19,15  say  "deleted!" 

wait 
clear 

close  databases 
return 
endif 

if  CHOICE  =  1 
clear 
text 

WARNING:  Do  not  change  the  serial  number  on  this 
requisition  because  this  program  does  not  check  for 
duplicate  numbers  like  the  program  that  originally 
created  it.  (  option  3  ) 
endtext 
7 

wait 

clear 

set  format  to  ADDREQUI 

read 

close  format 

endif 

if  CHOICE  =  2 

delete  record  recno() 

set  talk  on 

pack 

set  talk  off 
endif 

else 

@  12,10  say  "Requisition  "+ltrim(str(NUMBER) )+"  is  not  found  " 
@  13,10  say  "in  the  file.  Return  to  the  Requisition" 
@  14,10  say  "  Management  main  menu  and  check  serial" 
@  15,10  say  "  number  with  option  1  or  2." 

wait 

clear 

close  databases 

return 


endif 
endif 
enddo 
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MISCREQ.PRG 


*MISCREQ.PRG 

*  This  program  gives  miscellaneous  information  about 
* requisitioning. 

*  Written  by  LT.  Steven  L.  Smith,  USN  14  June,  1987 

clear 

close  databases 


@  1, 
@  2, 

text 


3  to  3,  76  double 

3  say  "Cancellations,  Follow-up,  Modifications,  Misc.  Info" 

I.   General. 

Cancellations,  follow-ups  and  modifications  to 
requisitions  are  infrequent  events  that  you  may  someday 
have  to  do.  Since  these  are  not  common,  this  program 
only  refers  you  to  the  publications  that  deal  with  them. 
The  SAMS  program  will  still  be  useful  to  you  in  creating 
these  documents. 

IMPORTANT  **  Note  that  the  fleet  commanders  and 
operational  commanders  promulgate  specific  instructions 
concerning  ammunition  requisitioning  and  reporting.  As 
weapons  personnel  you  should  keep  current  on  these 
because  they  deal  with  your  ship' s  particular  area  of 
operations . 

Specifically: 


endtext 

wait 

@  4,  0  clear 

text 


Pacific  Fleet  -  (a) 


CINCPACFT.TINST  8010.12 
"Pacific  Fleet  Conventional  Ordnance 
Management  Manual" 
section  1  and  appendices  1-10 

(b)  COMSUBPACINST  C8500.1 
^COMSUBPAC  Ordnance  Notes" 


Atlantic  Fleet 


(a)  CINCLANTFLTINST  8010.4 

"Atlantic  Fleet  Reporting  an 
Requisitioning  Guide" 

(b) 


endtext 

wait 

@  4,  0  clear 

•> 

text 


II.  Requisition  Follow  -  Up 

(a)  SPCCINST  8010. 12D,  Section  8  -  215 

(b)  NAVSUP  Pub.  485,  chap.  3,  part  D,  section  II, 

subsection  1,  3530  -  3537 

III.  Requisition  Modifications 
(a)    SPCCINST  8010. 12D,  section  8 


213,214 
NAVSUP  Pub.  485,  Chap.  3,  part  D,  section  II, 
subsection  2,  3550  -  3552 

IV.  Requisition  Cancellation 

SPCCINST  8010. 12D,  section  8  -  216 
NAVSUP  Pub.  485,  chap.  3,  part  D,  section  II 
subsection  3,  3565  -  3573 

endtext 

wait 

@  4,  0  clear 


(81 
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text 

V.  MILSTRIP  Status  Documents 


endtext 

wait 

(§4,0  clear 

text 


(a)  SPCCINST  3010. 12D,  section  8  -  212 

(b)  NAVSUP  Pub.  435,  chap.  3,  part  D,  section  I, 

3506  -  3511 
These  documents  or  messages  that  the  supply  system 
provides  you  are  in  response  to  the  status  you  requested 
via  the  Media  and  Status  code  on  your  requisition. 

VI.  Supplemental  Requisition  Procedures 

(a)  SPCCINST  8010. 12D,  section  8  -  217 

1.  8E  cog  material  -  Air  launched  missile  material 

(  HARPOCN  ) 

2.  8T  cog  material  -  Surfaced  launched  guided 

missile  material 


3.  *4T  cog  material  -  Torpedoes  and  components 

ASROC 
*8S  cog  material  -  SUBR0C  material 
*8U  cog  material  -  Sonobouys 

*  Refers  you  to  Fleet  instructions 

4.  2D  cog  material  -  Tomahawk 


endtext 

wait  "Press  any  key  to  return  to  Requisition  Management  menu 

return 


8.        PRINTREQ.PRG 

*   PRINTREQ.PRG 

-ir 

Steve'n  L.  Smith,  USN  16  June,  1987 


Program  to  print  requisition  documents 
Written  by  LT, 


store  1  to  REQNO 
*set  talk  on 
*set  echo  on 
*set  step  on 

do  while  .T. 
clear 
close  databases 

@  1,  10  to  3,  60  double 

@  2,  15  say  "Printing  Requisitions" 

■> 

■> 

text 

What  kind  of  requisition  format  would  you  like? 

1.  Manual   (  DD  Form  1348  ) 

2.  Naval  message 

3.  DAAS  message 

4.  Return  to  previous  menu 

endtext 

store  0  to  CHOICE 

@  20,  20  say  "  Enter  your  choice:  "  get  CHOICE  picture  "9 

range  1,4 
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IIQII 


read 

if  CHOICE  =  4 

return 
endif 

******  Look  up  requisition  and  load  data  into  variables**** 

@  4,  0  clear 
store  0  to  NUMBER 

@  3,  10  say  "What  is  the  serial  number  of  the" 
@  9,  10  say  "requisition  that  you  wish  to  print?"; 
get  NUMBER  picture  "9999"  range  8000,8999 
read 

sslfict  A 

use  AMREQUIS  index  AMRSERUP 

eel ^rt  R 

use  AMMODATA  index  AMANIIN 
s q  ~Lq c t  A 
set  relation  to  NUN  into  AMMODATA 

seek  NUMBER 

if  found() 

@  12,  10  say  "Requisition  "+ltrim(str(NUMBER) )+"  is  for:" 
(3  13,10  say  B->SHORTTITLE 

©14,  10  say  "  NALC :  "+B->NALC+"   NUN:  "+NIIN+; 
"   QUANTITY:  "+QUANTITY 

do  while  .T. 

store  "  "  to  MCHOICE 
@  16,15  say  "Is  this  the  correct  requisition? (Y/N)" ; 
get  MCHOICE  picture  "!" 
read 

do  case 

case  MCHOICE  =  "Y" 
exit 

case  MCHOICE  =  "N" 

@  18,  15  say  "Return  to  Requisition  Management  main" 

@  19,  15  say  "menu  and  check  serial  number  with" 

@  20,  15  say  "  option  1  or  2." 
■? 

wait 

clear 

close  databases 

return 

otherwise 

@  18,15  say  "Not  a  valid  selection,  press  " 
@  19,  15  say  "any  key  to  try  again:  " 

wait*  " 

@  16,  0  clear 

endcase 

enddo 

if  REQUISSTAT  =  "I" 

@  18,10  say  "WARNING:  This  item's  requisition  status  " 
@  19,  10  say  "indicates  it  is  not  ready  for  submission.  " 
@  20,  10  say  "Recommend  checking  an/or  updating  status." 

wait 

clear 

close  databases 

return 
endif 

store  B->FEDSUPCLAS  to  APROD 
store  B->COGSYMBOL  to  BPROD 
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store  B->UNITOFISSU  to  CPROD 
store  B->SECRISKCOD  to  XPROD  - 

set  relation  to 

store  SENDTOUIC  to  DPROD 
store  SUPADDUIC  to  EPROD 

select  C 

use  AMDADDR  index  AMDUIC 

goto  top 

seek  DPROD 

if  found() 

store  ACTIVNAME  to  FPROD 

store  LOCATION  to  GPROD 

store  HULLNUMBER  to  YPROD 

store  ROUTIDENT  to  ZPROD 
else 

store  ■■       "  to  FPROD 

store  "       "  to  GPROD 

store  "      "  to  YPROD 

store  "   "  to  ZPROD 
endif 

goto  top 
seek  EPROD 

if  found() 

store  ACTIVNAME  to  HPROD 

store  LOCATION  to  IPROD 
else 

store  "         "  to  HPROD 

store  "  "  to  IPROD 

endif 

use 

select  D 

use  AMSTDATA 

store  SERVCODE  to  JPROD 

score  UIC  to  KPROD 

store  ltrim(UNITNAME)  to  LPROD 

store  HULLNUMBER  to  MPROD 

store  FUNDCODE  to  NPROD 

store  MONITACTIV  to  OPROD 
use 

select  A 
endif 

if  .not.  found() 
clear 

@  12,15  say  "Requisition  "+ltrim(str (NUMBER) )+"  is  not" 

{§  13,15  say  "found  in  the  file.  Return  to  the  " 

d  14,15  say  "Requisition  Management  main  menu  and  " 

d  15,15  say  "check  the  serial  number  with  options  " 

@  16,15  say  "  1  and  2." 

-> 

wait 

clear 

close  databases 

return 

endif 

********Finished  loading  requisition  data  into  variables*** 

******  Process  manual  requisition  DD  Form  1348  ******* 

if  CHOICE  =  1 
clear 
@  1,  15  to  3,  50 


text 


@  2,  20  say  "Manual  Requisition" 
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Notes:  A  DD  Form  1348  can  not  be  produced  on  most  common 
computer  printers  because  of  its  size  and  lack  of 
tractor  feed  holes.  In  any  case  you  would  have  to 
remove  the  normal  paper. 

This  program  will  produce  a  near  replica  of  the 
completed  DD  Form  1348  on  the  screen  and  then  you 
will  have  to  transfer  the  exact  data  to  the  DD 
Form  1348(6-part)  card. 

You  should  use  a  black  ball  point  pen,  pressing 
firmly,  or  use  a  typewriter  set  at  10  pitch. 
Attempt  to  keep  the  characters  within  the  "tick- 
marks11.  Use  0  (with  a  slash  through)  for  the 
number  zero, 
endtext 
■p 

wait 

do  REQ1348.PRG 

@  20,10  say  "Press  any  key  to  return-" 
wait  "  " 

endif 

********  Finished  processing  manual  requisition  ******** 

****Process  information  common  to  DAAS  and  narrative  messages  * 

if  CHOICE  =2   .OR.  CHOICE  =  3 
clear 
@  0,15  to  2,60  double 

@  1,25  say  "Special  message  information" 

■? 

•> 

text 
NOTE:  During  periods  of  restricted  communications  (  ie 
MINIMIZE),  message  requisitions  shall  only  be  transmitted 
for  priorities  01-08  requirements. 

endtext 

@  3,2  to  8,75 

******  special  addressing  info,  for  certain  COG  material 

text 
Comments:  The  action  and  info  addees  on  naval  message 
requisitions  vary  widely  depending  on  the  type  of  material 
(COG),  and  the  theatre  of  operations.  Due  to  the  frequency  of 
change  and  the  variability  of  these  addresses,  any  attempt  to 
automate  the  choice  of  these  would  quickly  be  in  error. 

If  your  requisition  involves  COG  material  that  falls  in 
special  categories,  the  program  will  warn  you  and  direct  you 
to  one  of  the  references, 
endtext 

wait 

@  3,0  clear 

do  case 

case  (BPROD  =  "4E")  .OR.  (BPROD  =  "8E") 
text 
**  Your  requisition  is  for  Air  Launched  Missile  Material 
(COG  4E  or  8E),  refer  to  CINCPACFLTINST  8010.12,  section 
1,  App.  4  or  App.  9 'HARPOON)  or  CINCLANTFLTINST  8010. 4H 

endtext 

case  BPROD  =  "8T" 
text 
**  Your  requisition  is  for  Surfaced  Launched  Guided 
Missile  Material  (COG  8T) ,  refer  to  CINCPACFLTINST 

162 


8010.12  section  1,  App.  7  or  CINCLANTFLTINST  8010. 4H 

endtext 

case  BPROD  =  "4T" 
text 
**  Your  requisition  is  for  torpedoes  and  components  or 
ASROC  and  components  (COG  4T)  ,  refer  to 
CINCPACFLTINST  8010.12  section  1,  App.  5  or 
CINCLANTFLTINST  8010. 4H 

endtext 

case  BPROD  =  "8S" 
text 
**  Your  requisition  is  for  SUBROC  material  (COG  8S), 
refer  to  CINCPACFLTINST  8010.12  section  1,  App.  5 
or  CINCLANTFLTINST  8010. 4H 
endtext 

case  BPROD  =  "8U" 

text 
**  Your  requisition  is  for  sonobouy  material  (COG 
8U),  refer  to  CINCPACFLTINST  8010.12  section  1, 
App.  8  or  CINCLANTFLTINST  8010.4H 
endtext 

case  BPROD  =  "2D" 
text 

**  Your  requisition  is  for  Tomahawk  material  (COG 
2D),  refer  to  CINCPACFLTINST  8010.12,  section  1, 
App.  10  or  CINCLANTFLTINST  8010. 4H 
endtext 

case  BPROD  =  "6T" 

text 
**  Your  requisition  is  for  mine  material  (COG  6T), 
refer  to  CINCPACFLTINST  8010.12  section  1,  App.  6 
or  CINCLANTFLT  8010. 4H 
endtext 

case  (BPROD  =  "2T")  .OR.  (BPROD  =  "2E") 
do  while  .T. 

store  "  "  to  BCHOICE 
@  5,5  say  "Is  your  requisition  for  mine  material? (Y/N) " ; 
get  BCHOICE  picture  "!" 
read 
do  case 

case  BCHOICE  =  "Y" 
@  7,0  clear 
text 
**  Refer  to  CINCPACFLTINST  8010.12  section  1, 
App. 6  or  CINCLANTFLTINST  8010. 4H 
endtext 
exit 

case  BCHOICE  =  "N" 
@  4,0  clear 
text 
**  Your  requisition  is  for  normal  conventional 
ammunition  (Cog  2T  or  2E(air)).  Your  "normal" 
requisition  action  and  info  addees  are: 

Pacific  Fleet  Atlantic  Fleet 

EastPac     MidPac       WestPac 


A  Conus  Ord.  Activity    Ord.  Activity 
C  SPCC  or  DAAS  SPCC  or  DAAS 

T    (message)  (message) 


I       TYCOM  TYCOM 

N  COMNAVLOGPAC  COMNAVLOGPAC 

F      ISIC  CTF  SEVEN  THREE 

O  LOADOUT  ACTIVITY  ISIC 
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LOADOUT  ACTIVITY! 


Ref:  CINCPACFLTINST  8010.12  section  1,  App.  3 
CINCLANTFLTINST  8010. 4H 

endtext 

exit 


otherwise 

waif'Not  valid  selection, press  a  key" 

@  5,0  clear 


enddo 
endcase 

wait 


endcase 


*******  End  of  special  addressing  info. 

*****************     Collecting  Addresses  ***************** 

if  REQNO  =  1 

store  space(35)  to  ADDRES1 ,ADDRES2 ,ADDRES3 ,ADDRES4, ; 

ADDRES5,ADDRES6,ADDRES7,ADDRES8,ADDRES9 


do  while  .T. 
clear 

@  1,10  to  3,60  double 
d  2,15  say  "Message  Action  and  Info.  Addees" 

text 
Enter  the  appropriate  addresses  in  the  order  you  wish  them  to 
appear  on  the  message.  Use  the  cursor  keys  to  move  around  and 
edit.  Address  format:  ACTIVITY  LOCATION 

endtext 

@  7,0  to  7,79 

if  CHOICE  =  2 

ADDRES1  =  "SPCC  Mechanicsburg,  PA." 
endif 
if  CHOICE  =  3 

ADDRES1  =  "DAAS  Dayton  OH." 
endif 

get  ADDRES1 
get  ADDRES2 
get  ADDRES3 
get  ADDRES4 
get  ADDRES5 
get  ADDRES6 
get  ADDRES7 
get  ADDRES8 
get  ADDRES9 


@  9,15  say  "Action  Addressee: 

1. 

@  10,15  say  " 

2. 

@  11,15  say  " 

3. 

@  13,15  say  "Info.  Addressee: 

1. 

@  14,15  say  " 

2. 

@  15,15  say  " 

3. 

@  16,15  say  " 

4. 

@  17,15  say  " 

5. 

@  18,15  say  " 

6. 

@  19,0  to  19,78 

do  while  .T. 

store  "  "  to  DCHOICE 

@  20,2  say  "(R)Review  address  file   (S)Save   (M)Modify; 
addees   (X)Exit" 

@  21,10  say  "Enter  choice:  "  get  DCHOICE  picture  "!" 
read 

do  case 

case  DCHOICE  =  "R" 
do  REVWADD 
select  A 
exit 

case  DCHOICE  =  "M" 
exit 

case  DCHOICE  =  "S" 
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enddo 


enddo 


exit 

case  DCHOICE  =  "X" 
exit 

otherwise 
@  22,10  say  "Invalid  selection, 
wait 

@  20,0  clear 
endcase 

if  DCHOICE  =  "S"  .OR.  DCHOICE  =  "X" 
exit 

endif 


if  DCHOICE  =  "X" 

loop 
endif 
endif 

**:;»c**********£ncj  Collecting  Addresses********* 

************Classification  Determination********** 
if  REQNO  =  1 
clear 
store  "  "  to  CLASS 

@  0,10  to  2,60  double 

(§1,15  say  "Message  classification  information" 

text 

A  DAAS  formatted  message  is  always  UNCLASSIFED  because  none 

of  the  MILSTRIP  data  elements  contain  classified 

information. 

NOTE:  Other  technical  or  operational  information  about  a 
particular  item  may  be  classified  however,  such  as 
for  torpedoes,  some  missiles  and  rockets , etc. . 

A  narrative  message  is  likewise  UNCLASSIFIED  unless  you 
must  add  a  REMARKS  paragraph  that  contains  classified 
information  such  as  ship's  schedule  or  other  operational 
information. 

NOTE:   CINCLANTFLT  does  not  permit  classified  requisitions. 
A  separate  classified  message  is  required, 
endtext 

do  while  .T. 

store  "  "  to  ECHOICE 

@  19,5  say  "Will  you  require  a  classified  REMARKS  paragraph; 
?(Y/N)"  get  ECHOICE  picture  " ! " 

read 

if  ECHOICE  =  "Y" 

@  22,10  say  "Enter  the  classification  of  the  remarks:"; 
get  CLASS  picture  "!!!!!!!!!!!!" 
read 
exit 

else 

if  ECHOICE  =  "N" 

CLASS  =  "UNCLAS" 
exit 

else 

@  22,10  say  "Invalid  entry,  press  any  key.." 
wait"  " 
@  19,0  clear 
endif 
endif 
enddo 
endif 
*************  jrnc2  classification  Determination  ********* 
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**********   End  of  common  information  ************* 
endif 


**********   printing  the  message  worksheet  ******** 
if  CHOICE  =  2 

if  REQNO  =  1 

clear 

@  5,5  say  "Ensure  the  printer  is  on  and  the  paper  aligned  to1 

@  6,5  say  "start  printing  at  the  top  of  a  sheet" 

waif'Press  any  key  to  start  printing" 

clear 

@  10,10  say  "Printing  message  requisition" 

@  11,10  say  "Please  do  not  disturb  until  return  to  menu.." 

<§  9,5  to  12,60  double 

set  device  to  print 

@  1,5  say  "Ammunition  Requisition  Message  Worksheet" 

5  2,5  say  "Security  classification  =  "+CLASS 

(§3,10  say  "LMF  =  TT       CIC  =  ZYUW" 

@  4,0  say  " 

@  6,12  say  "From:  "+LPROD 
@  7,14  say  "To:  "+ADDRES1 
if  ADDRES2  <>  " 

@  prow()+l,18  say  ADDRES2 
endif 
if  ADDRES3  <>  "    " 

@  prow()+l,18  say  ADDRES3 
endif 
@  prow()+l,12  say  "Info:  "+ADDRES4 
if  ADDRES5  <>  " 

@  prow()+l,18  say  ADDRES5 
endif 
if  ADDRES6  <>  "    " 

@  prow()+l,18  say  ADDRES6 
endif 
if  ADDRES7  <>  "     " 

@  prow()+l,18  say  ADDRES7 
endif 
if  ADDRES8  <>  "    " 

@  prow()+l,18  say  ADDRES8 
endif 
if  ADDRES9  <>  "    " 

@  prow()+l,18  say  ADDRES9 
endif 


@  prow()+2,0  say  trim(CLASS) 

@  prow(),pcol()+l  say  "//8012//" 

0  prow()+l,0  say  "Subj :  AMMO  MILSTRIP  REQUISITION" 

endif 

if  REQNO  >  1 

clear 

@  10,15  say  "Printing, do  not  disturb" 

@  9,5  to  11,40   double 

set  device  to  print 
endif 

@  prow()+2,0  say  ltrim(str(REQNO) )  +".  " 

if  CLASS  <>  "UNCLAS" 

@  prow(),pcol()  say  "(U)  " 
endif 

@  prow() ,pcol()  say  DOCIDENTIF+"/"+ZPROD  +"/"+MEDIASTAT  +"/" 

store  1  to  MARK 

store  "    "  to  tempi 

store  "  "  to  temp2 

store  "     "  to  POSIT 
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tempi  =  ltrim(str(APROD)) 

do  while  MARK  <  5 

temp2  =  substr( tempi  ,MARK,  1) 

do  SPELLIT  with  temp2,  POSIT 
@  prow(),pcol()  say  ltrim(POSIT)  +  "  " 
MARK  =  MARK  +  1 
enddo 

store  1  to  MARK 

do  while  MARK  <  10 

temo2  =  substr(NIIN,  MARK,  1) 
do  SPELLIT  with  temp2 ,  POSIT 
if  MARK  =  7 

@  prow()+l,0  say  ltrim(POSIT)  +  "  " 
endif 
@  prow() ,pcol()  say  ltrim(POSIT)  +  "  " 
MARK  =  MARK  +  1 
enddo 

@  prow(),pcol()-l  say  "/"+CPROD  +"/" 

store  1  to  MARK 

do  while  MARK  <  6 

terr.p2  =  substr (QUANTITY ,  MARK,  1) 

do  SPELLIT  with  temp2,  POSIT 

@  prow() ,pcol()  say  ltrim(POSIT)  +  "  " 

MARK  =  MARK  +  1 
enddo 

@  prow() ,pcol()-l  say  ,7"+JPROD+KPROD+'7"+JULIANDATE+l7"+; 
Itr im (str (SERIAL) )+"7"+DEMANDCODE+"/"+chr( 10) 
@  prow(),0  say  SUPADDSERC+SUPADDUIC+"/" ; 
+SIGNALCODE+l7"+NPROD+l7"+OPROD+BPROD+; 
,7ll+PROJCODE+,7"+PRIORITYCD+,7"+REQDELDATE-^l7"+ADVICECODE+chr(10) 

set  device  to  screen 

clear 

****  Determine  if  more  messages  will  be  printed 

text 

Choose  one:   1.  More  message  requisitions  to  print  with 

same  addresses  and  classification. 

2.  More  message  requisitions  to  print  with 

different  addresses  and/or  classification, 

3.  Add  narrative  remarks  paragraph 

4.  Finished  message  requisitions 

endtext 

store  0  to  GCHOICE 

@  12,15  say  "Enter  Choice:  "  get  GCHOICE  picture  "9"  range  1,4 
read 

do  case 

case  GCHOICE  =  1 
REQNO  =  REQNO  +  1 
clear 

@  5,5  say  "Do  not  advance  printer,  next" 
@  6,5  say  "requisition  will  print  as  paragraph" 
@  7,5  say  "2, 3, etc. ." 

wait 

case  GCHOICE  =  2 
clear 

set  device  to  print 
@  prow()+2,0  say  "BT"+chr(10) 
set  device  to  screen 

(§5,5  say  "Remove  previous  message  worksheet" 
@  6,5  say  "from  printer,  set  up  for  the  next" 
@  7,5  say  "printed  message  worksheet" 
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REQNO  =  1 
wait 

case  GCHOICE  =  3 

store  space (254)  to  COMMENTS 
clear 

@  5,5  say  "Enter  remarks:  "  get  COMMENTS 
read 

set  device  to  print 
@  prow()+2,0  say  ltrim(str( (REQNO  +1)))+".  " 
if  CLASS  =  "CONFIDENTIAL" 

@  prow(),pcol()  say  "(C)  " 
endif 
if  CLASS  =  "SECRET" 

@  prow() ,pcol()  say  "(S)  " 
endif 

@  prow() ,pcol()  say  "Remarks:  "+  trim (COMMENTS) 

@  prow()+2,0  say  "BT"+chr(10) 
set  device  to  screen 

REQNO  =  1 
clear 

case  GCHOICE  =  4 
REQNO  =  1 
clear 

set  device  to  print 
@  prow()+2,0  say  "BT"+chr(10) 
set  device  to  screen 

endcase 

endif 

*****   process  DAAS  formatted  message  ************** 

if  CHOICE  =  3 
if  REQNO  =  1 

clear 

@  0,15  to  2,50  double 

@  1,20  say  "DAAS  message  information" 

text 
The  Defense  Automated  Addressing  System(DAAS)  is  a  real-time 
telecommunications  system  located  in  Dayton,  OH.  which  is 
designed  to  effectively  route  logistics  traffic  to  supply 
sources.  DAAS  messages  are  submitted  in  a  fixed,  machine  - 
readable  format  which  does  not  have  to  be  transcribed  for 
entry  into  the  CAIMS  sytem  as  do  narrative  messages  or  manual 
requisitions . 

************   q^AS  MESSAGES  **************** 

1.  Must  be  UNCLASSIFIED. 

2.  Must  not  require  REMARKS. 

3.  Must  be  to  CONUS  activities  only. 

4.  Must  not  be  for  CV  lcadouts  from  AOE/AE. 
endtext 

@  10,5  to  16,62  double 

text 
For  more  information  on  DAAS  read:  NAVSUP  Pub  485, section 
3028.  SPCCINST  8010. 12D,  section  8-207,  CINCPACFLTINST, 
section  1-5  or  CINCLANTFLTINST  8010. 4H,  section 

endtext 

do  while  .T. 

store  "  "  to  HCHOICE 

@  21,5  say  "Is  DAAS  format  still  O.K.?(Y/N)"  get  HCHOICE; 
picture 


n  i  H 


read 
do  case 
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case  HCHOICE  =  "Y" 
clear 
exit 

case  HCHOICE  =  "N" 
clear 

exit 

otherwise 
@  23,10  say  "Invalid  entry,  press  any  key, 
wait"  " 
@  21,0  clear 

endcase 

enddo 

if  HCHOICE  =  "N" 

loop 
endif 

@  5,5  say  "Ensure  the  printer  is  on  and  the  paper  aligned" 
(§6,5  say  "to  start  printing  at  the  top  of  a  sheet." 

waif'Press  any  key  to  start  printing" 

clear 

@  10,10  say  "Printing  DAAS  message  requisition--" 

@  11,10  say  "Please  do  not  disturb  until  return  to  menu." 

@  9,5  to  12,60  double 

set  device  to  print 

@  1,5  say  "DAAS  Requisition  message  worksheet" 

@  2,5  say  "Security  classification  =  UNCLAS" 

(§3,10  say  "LMF  =  TT  CIC  =  ZYUW  " 

@  4,0  say  " " 

@  6,12  say  "From:  "+LPR0D 
@  7,14  say  "To:  "+ADDRES1 
if  ADDRES2  <>  "    " 

@  prow()-H,18  say  ADDRES2 
endif 
if  ADDRES3  <>  "    " 

@  prow()+l,18  say  ADDRES3 
endif 
@  prow()+l,12  say  "Info:  "+ADDRES4 
if  ADDRES5  <>  " 

@  prow()+l,18  say  ADDRES5 
endif 
if  ADDRES6  <>  "     " 

@  prow()+l,18  say  ADDRES6 
endif 
if  ADDRES7  <>  "     " 

@  prow()+l,18  say  ADDRES7 
endif 
if  ADDRES8  <>  "    " 

@  prow()+l,18  say  ADDRES8 
endif 
if  ADDRES9  <>  "     " 

@  prow()+l,18  say  ADDRES9 
endif 

@  prow()+l,0  say  "Subj :  AMMO  MILSTRIP  REQN." 

endif 

if  REQNO  >  1 
clear 

@  10,15  say  "Printing,  do  not  disturb." 
@  9,10  to  11,45  double 
set  device  to  print 
endif 

if  REQNO  =  1 

@  prow()+4,5  say  DOCIDENTIF+ZPROD+MEDIASTAT+; 
ltrim(str(A?ROD))+NIIM+"   "+CPROD+QUANTITY+JPROD+KPROD+; 
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JULIANDATE+ltrim(str (SERIAL) )+DEMANDCODE+SUPADDSERC+ ; 
SUPADDUIC+SIGNALC0DE+NPR0D+0PR0D+BPR0D+PROJC0DE+; 
PRIORITYCD+REQDELDATE+ADVICECODE+chr ( 10 ) 

endif 

if  REQNO  >  1 

@  prow()+l,5  say  DOCIDENTIF+ZPROD+MEDIASTAT+; 
ltrim(str(APROD))+NIIN+"   "+CPROD+QUANTITY+JPROD+KPROD+ ; 
JULIANDATE+1 trim (str( SERIAL )) +DEMANDCODE+SUPADDSERC+; 
SUPADDUIC+SIGNALCODE+NPROD+OPROD+BPROD+PROJCODE+; 
PRIORITYCD+REQDELDATE+ADVICECODE+chr(10) 

endif 

set  device  to  screen 
clear 

********  Determine  if  more  requisitions  on  same  message** 

text 

Choose  one : 

1.  More  requisitions  to  print  with  same 

action  and  info,  addresses. 

2.  More  requisitions  to  print  with  different 

action  and/or  info,  addresses. 

3.  Finished  DAAS  message  requisition, 
endtext 

store  0  to  I CHOICE 

@  12,15  say  "Enter  choice:  "  get  ICHOICE  picture  "9"  ; 

range  1,3 
read 

do  case 

case  ICHOICE  =  1 
REQNO  =  REQNO  +  1 
clear 

(§5,5  say  "Do  not  advance  printer,  next" 
@  6,5  say  "requisition  will  print  below" 
@  7,5  say  "previous  one." 

wait 

case  ICHOICE  =  2 
clear 

@  5 , 5  say  "Remove  worksheet  from  printer," 
@  6,5  say  "set  up  paper  for  next  message." 

■? 

REQNO  =  1 
wait 

case  ICHOICE  =  3 
clear 
REQNO  =  1 

endcase 

endif 


*********  jrncj  daaS  formatted  message  ************** 

enddo 

close  databases 
clear  all 
return 
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9.       PROGFILE.PRG 

*  PROGFILE.PRG 

x  This  program  reviews  the  system  program  file  and  prints  it  if 
x  desired. 

*  Written  by  LT.  Steven  L.  Smith,  USN  13  July,  1987 

*  Activate  next  two  items  if  program  used  alone, 
set  talk  off 

set  status  off 
set  bell  off 

clear 

£  5,15  sav  "SAMS  Proaram  File" 

@  4,10  to* 5,45   double 

■? 

■> 

text 

What  would  you  like  to  do? 

1 .  Review  the  program  file 

2.  Print  the  program  file 

3.  Quit 
endtext 

store  0  to  ITEM 

@  20,10  say  "Enter  choice:  "  get  ITEM  picture  "9"  range  1,3 
read 

do  case 

case  ITEM  =  1 
clear 

use  PROGFILE  index  PROGNAME 
do  while  .T. 

store  1  to  MLINE 
store  1  to  MCOUNT 

do  while  (MCOUNT  <=3)  .AND.  (.NOT.  eof()) 

@  MLINE, 5  say  "Program  Name:  "+PROG_NAME 
@  MLINE+1,5  say  "Calls:  "+rtrim(CALLS) 
@  MLINE+3,5  say  "Purpose:  "+rtrim(PURPOSE) 
@  MLINE+5,5  say  "Called  by:  "+rtrim(CALLED_BY) 
@  MLINE+6,0  to  MLINE+6,78 

MLINE  =  MLINE  +  7 
MCOUNT  =  MCOUNT  +  1 
skip 

enddo 

if  eof() 

@  23,60  say  "End  of  File" 
endif 

do  while  .T. 

store  "  "  to  CHY 
@  22,5  say  " (C)Continue  (R)Repeat  (X)Exit: 
get  CHY  picture  "!" 
read 
do  case 

case  CHY  =  "C"  .OR.  CHY  =  "R" 
if  eof() 

goto  top 
endif 
exit 

case  CHY  =  "X" 
use 

clear 

set  talk  on 

set  status  on 

set  bell  on 

return 
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otherwise 
@  23,5  say  "Invalid  selection,  press  a  key- 
wait"  " 
@  22,0  clear 

endcase 
enddo 
clear 
enddo 

case  ITEM  =  2 
clear 

@  10,10  say  "Printing,  do  not  disturb" 
@  9,5  to  11,37   doubxe 
use  PROGFILE  index  PROGNAME 
set  device  to  print 

@  1,15  say  "SAMS  Program  File"+chr(10) 

@  prow(),0  say  " 

"+chr(10) 

@  prow(  )  ,0  say  " 


■+chr(10) 


do  while  .NOT.  eof() 

@  prow()+2,5  say  "Program  Name:  "+PROG_NAME+chr(10) 

@  prow{),5  say  flCalls:  "+CALLS+chr(10) 

@  prow(),5  say  "Purpose:  "+PURPOSE+chr(10) 

@  prow(),5  say  "Called  by:  "+CALLED_BY+chr(10) 

@  prow(),0  say  " 

"+chr(10) 


*      skip 
enddo 

use 

set  device  to  screen 


case  ITEM  =  3 
clear 

@  10,10  say  "Quit  this  program1 
use 
wait 

set  talk  on 
set  status  on 
set  bell  on 
return 


endcase 

set  talk  on 
set  status  on 
set  bell  on 

return 


10.      REQ1348.PRG 

*  REQ1348.PRG 

*  Program  to  display  replica  of  DD  Form  1348  filled  in 

*  Written  by  LT.  Steven  L.  Smith,  USN    16  June, 1987 
clear 

@   1,   3   SAY  SENDTOSERC 
@   1,   4   SAY  SENDTOUIC 
@   1,  10   SAY   FPROD 

if  SENDTOSERC  =  "V"  .OR.  SENDTOSERC  =  "R" 
@  2,  13  say  YPROD 

else 
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endif 


@  2,    12   say  GPROD 


@  1 

40 

SAY 

JPROD 

@    1 

41 

SAY 

KPROD 

(?    1 

48 

SAY 

LPROD 

@  2 

45 

SAY 

MPROD 

@   5 

2 

SAY 

"XXXXXXXXXXXXX  XXXXXXXX" 

@   5 

25 

SAY 

AMREQUIS->DOCIDENTIF 

@   5 

30 

SAY 

ZPROD 

9   5 

36 

SAY 

AMREQUIS->MEDIASTAT 

3  5 

40 

SAY 

ltrim(str(APROD)) 

3  5 

49 

SAY 

AMREQUIS->NIIN 

@   5 

62 

SAY 

"XX" 

@   5 

67 

SAY 

CPROD 

@   5 

71 

SAY 

AMREQUIS->OUANTITY 

@  3 

2 

SAY 

JPROD 

3  3 

3 

SAY 

KPROD 

■3  7 

40 

SAY 

"Remarks :" 

@  8 

11 

SAY 

AMREQUIS->JULIANDATE 

@  8 

17 

SAY 

AMREQUIS->SERIAL 

@  8 

23 

SAY 

AMREQUIS->DEKANDCODE 

@  8, 

27 

SAY 

AMREOUIS->SUPADDSERC 

3  8 

28 

SAY 

AHREQUIS->SUPADDUIC 

@  3 

36 

SAY 

AMREQUIS->SIGMALCODE 

@  11, 

2 

SAY 

NPROD 

@  11, 

6 

SAY 

OPROD 

@  11, 

7 

SAY 

BPROD 

@  11 

10 

SAY 

AHREQUIS->PROJCODE 

@  11 

14 

SAY 

AMREQUIS->PRIORITYCD 

@  11, 

17 

SAY 

AHREQUIS->REQDELDATE 

@  11, 

21 

SAY 

1 '  XXXXXXXXXXXXXXXXX ' ' 

3  14, 

2 

SAY 

AMREQUIS->ADVICECODE 

■3  14, 

6 

SAY 

" XXXXXXXXXXXXXXXXXXXXXXXXXXX " 

(3  16 

16 

SAY 

"DD  Form  1348  -  Manual  Requisition" 

•3  3 

2 

TO 

3,  77 

f?  6, 

2 

TO 

6, 

77 

?  9 

2 

TO 

9 

77 

@  12 

2 

to  : 

L2 

77 

@  0 

1 

to  : 

L5 

73    DOUBLE 

@   1 

33 

TO 

5 

38 

@  7 

33 

to 

1] 

.,38    double 

@  4 

35 

TO 

5 

35 

@  4 

29 

TO 

5 

29 

@  4 

24 

TO 

5 

24 

@  4 

15 

TO 

5 

15 

{§  4 

70 

TO 

5 

70 

5  4 

65 

TO 

5 

65 

ft  4 

45 

TO 

5 

45 

(§  4 

51 

TO 

5 

61 

@  7 

35 

TO 

8 

35 

@  7 

24 

TO 

8 

24 

'3  7 

21 

TO 

8 

21 

@  10 

20 

TO 

LI 

20 

@  10 

16 

to  : 

LI 

16 

@  10 

13 

TO 

LI 

13 

@  10 

9 

TO  . 

LI 

,   9 

@  10 

5 

TO  . 

LI 

5 

@  13 

5 

TO 

L4 

,   5 

@  13 

33 

TO 

L4 

33       double 

@  13 

,  29 

TO 

L4 

,  29 

retui 

-n 
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11.      REQMENU.PRG 

*REQMENU.PRG 

^Program  to  present  the  Requisition  Management  Menu 

^Written  by  LT.  Steven  L.  Smith,  USN  ,  6  June,  1987 

Clear  all 
do  while  .T. 


clear 
text 


Requisition  Management  Menu 

1.  Review  all  requisitions  -  Summary 

2.  Review  complete  requisition  data 

3.  Create  a  new  requisition 

4.  Edit  and  delete  requisitions 

5.  Cancellation  Follow-up,  Modifications,  Info. 

6.  Print  requisition  documents 

7.  Backup  Requisition  File 

99.  Return  to  Main  Menu 
endtext 

@  1,0  to  21,79  double 
@  3,1  to  3,78 
@  18,1  to  18,78 

store  0  to  MSELECT 

@  19,22  say  "Enter  your  selection:  "  get  MSELECT  picture  "99" 

read 

do  case 

case  MSELECT  =  1 
do  REVWREQ.PRG 

case  MSELECT  =  2 
do  COMPLREQ.PRG 

case  MSELECT  =  3 
do  CRENEWRQ.PRG 

case  MSELECT  =  4 
do  EDITREQ.PRG 

case  MSELECT  =  5 

do  MISCREQ.PRG 

case  MSELECT  =  6 

do  PRINTREQ.PRG 

case  MSELECT  =  7 

do  BCKUPREQ.PRG 

case  MSELECT  =  99 
return 

otherwise 

@  22,16  say  "Not  a  valid  selection--" 

wait  "  Press  any  key  to  try  again-- 

endcase 

enddo  [.T.] 
clear  all 
return 
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12.      REWVADD.PRG 


*  REVWADD.PRG 

*  This  program  reviews  the  address  file   (library  module) 

*  Written  by  LT.  Steven  L.  Smith,  USN   20  June,  1937 

*  NOTE:  If  used  external  to  AMSMAIN,  activate  next  two  lines 

*  set  status  off 

*  set  talk  off 

clear 

@  1,15  to  3,55   double 

@  2,23  say  "Address  File" 

@  5,0  say  "S/C  UIC 

HULL  NO. 

@  6,0  to  6,79 

select  H 

use  AMDADDR  index  AMDACTNM 


ACTIVITY 
R/I" 


LOCATION 


do  while  .T. 

store  1  to  MCOUNT 
store  8  to  MLINE 

do  while  (MCOUNT  <=  10)  .AND.  (.NOT.  eof()) 

@  MLINE  ,1  say  SERVCODE 

3  MLINE  ,3  say  UIC 

@  MLINE  ,10  say  ACTIVNAME 

@  MLINE  ,35  sav  LOCATION 

@  MLINE  ,62  say  HULLNUMBER 

§  MLINE  ,73  say  ROUTIDENT 

MLINE  =  MLINE  +  1 
MCOUNT  =  MCOUNT  +  1 
skip 

enddo 

if  eof() 

@  20,50  say  "End  of  File" 
endif 

do  while  .T. 

store  "  "  to  ZCHOICE 

@  21,5  say  " (C)Continue ,  (R)Repeat,  (X)Exit:"  get  ZCHOICE; 
picture  " ! " 
read 
do  case 

case  ZCHOICE  =  "C"  .OR.  ZCHOICE  =  "R" 
if  eof() 

goto  top 
endif 
exit 

case  ZCHOICE  =  "X" 
use 
clear 
return 

otherwise 

@  22,20  say  "Invalid  selection,  press  any  key  to  try  again-" 

wait  "  " 
@  21,0  clear 

endcase 


enddo 

@  7,0  clear 


enddo 

use 

return 
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13.      REVWREQ.PRG 

*  REVWREQ.PRG 

*  Program  to  quickly  review  the  requisition  file 

*  Written  by  LT.  Steven  L.  Smith,  USN   13  June,  1937 

clear  all 

select  A 

use  AMMODATA  index  AMANIIN 

se lee t  B 

use  AMREQUIS  index  AMRSERDW,AMRSERUP,AMRREQDD 
set  relation  to  NUN  into  AMMODATA 


clear 

9  1, 

9  2, 


22  to  3,  49  double 

27  say  "Requisition  File" 


9  5,4  say  "SERIAL 
QUANTITY   STATUS 


NALC    NUN 
J/DATE  " 


SHORT  TITLE 


set  heading  off 
goto  top 

do  while  .T. 

9  1,  0  to  24,  79  double 
@  6,  1  to  6,78 
store  7  to  mline 
store  0  to  xcount 

do  while  (.not.  eof())  .AND.  (xcount  <  10) 

9  mline,  5  say  SERIAL 

@  mline,  13  say  A->NALC 

9  mline,  19  say  NUN 

9  mline,  30  say  A->SHORTTITLE 

9  mime,  55  say  QUANTITY 

9  mline,  65  say  REQUISSTAT 

9  mline,  73  say  JULIANDATE 

mline  =  mline  +  1 
xcount  =  xcount  +  1 


skip 

if  eof( 
9  1 
endif 
enddo 

do  while  .T. 
store 


5  say  "That's  all  the  requisitions  on  file 


"  to  CHOICE 
@  20 , 5  say  "Want  to  see  more  or  review  again? (Y/N)" ; 
get  CHOICE  picture  "!" 
read 

do  case 

case  CHOICE  =  "N" 
set  heading  on 
clear  all 
return 
case  CHOICE  =  "Y" 
if  eof() 

goto  top 
(I  6 ,  0  clear 
exit 
else 

9  6,  0  clear 
exit 
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endif 
case  CHOICE  <>  "N"  .AND.  CHOICE  <>  "Y" 
@21,5  say  "Not  a  valid  choice--" 
wait"    Press  any  key  to  try  again- 
@  19,  1  clear  to  23,73 


endcase 


enddo 
enddo 

clear  all 
return 


14.      SPELLIT.PRG 

x  Procedure  SPELLIT 

.his  program  returns  a  soelled  out  character  string  for  the 
x  character  number 
*  Written  by  LT.  Steven  L.  Smith,  USN  20  June,  1987 

procedure  SPELLIT 
parameters  temp2,  POSIT 

do  case 

case  temp2  =  "9" 

store  "NINE"  to  POSIT 
case  temp2  =  "8" 

store  "EIGHT"  to  POSIT 
case  temp2  =  "7" 

store  "SEVEN"  to  POSIT 
case  temp2  =  "6" 

store  "SIX"  to  POSIT 
case  temp2  =  "5" 

store  "FIVE"  to  POSIT 
case  temp2  =  "4" 

store  "FOUR"  to  POSIT 
case  temp2  =  "3" 

store  "THREE"  to  POSIT 
case  temp2  =  "2" 

store  "TWO"  to  FCSIT 
case  temp2  =  "1" 

store  "ONE"  to  POSIT 
case  temp2  =  "0" 

store  "ZERO"  to  POSIT 
endcase 

return 


15.      STRLCCRT.PRG 

*  STRUCCRT.PRG 

*  This  program  displays  the  SAMS  structure  charts 

*  Written  by  LT.  Steven  L.  Smith,  USN  13  July,  1987 

clear 

set  talk  off 

set  status  off 

d  10,20  say  "SAMS  Structure  Charts" 

@  8,15  to  12,46   double 

■?  20,10  say  "Press  any  key  to  start  viewing  charts--1 

wait"  " 

clear 

do  while  .T. 

text 


Shipboard  Ammunition  Management  System 
Major  Sub-system  Structure  Chart 
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AMSMAIN 


TRANMENU    REQMENU 


TURNMENU     NARSMENU 


INVMENU 


MANGMENU 


INFOMENU 


REPTMENU 


endtext 
wait 
clear 
text 


User  Access/Main  Menu 


PROTECT 


AMSMAIN 


endtext 
wait 

clear 
text 


General  Information/Documentation 


INFOMENU 


INFOHELP 


DOCCODES 


DOCDEFIN 


DOCREFS 


INFOTEXT 


DATAELEM 


endtext 
wait 
clear 
text 


Inventory/ Allowance /Ammunition  Information 


INVMENU 
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INWIEW 


INVAMMO 


INVALLOW 


endtext 
wait 
clear 
text 


Requisition  Management 


REQMENU 


REVWREQ   COMPLREQ    CRENEWREQ     EDITREQ     MISCREQ 


PRINTREQ 


BCKUPREQ 


endtext 

wait 

clear 

text 


REQ1348 


REVWADD 


Transaction  Management 


SPELLIT 


TRANMENU 


VIEWATR    CRENWATR 


EDITATR     BCKUPATR     PRINTATR 


REVWADD 


endtext 

wait 

clear 

text 


Generate  Internal  Reports 


REPTMENU 


INVREPT    OSRQREPT 


TRALREPT 


Other  Reports 
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endtext 
wait 
clear 
text 


NARS  Management 


NARSMENU 


REVNARSF 


REVNARAF 


PROCMAR 


BCKUPNAR 


endtext 
wait 
clear 
text 


Turn-in  Document  Management 


TURNMENU 


TURNREV 


BCKUPTUR 


CRENWTID   EDITTURN 


REVWADD 


PRINTTUR 


endtext 
wait 
clear 
text 


System  Management 


MANGMENU 


MANGSEC   MANGARCH   MANGRECV   MANGADHC   MANGINIT 

MANGDOC  


MANGEDIT 


BCKUPSYS 


DOCFILES    PROGFILE    STRUCCRT 


endtext 

wait 
clear 

do  while  .T. 
store  "  "  to  XYZ 

3  5,5  say  "Do  you  wish  to  review  the  charts  again? (Y/N) 
get  XYZ  picture  "I" 
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read 

do  case 

case  XYZ  =  "Y" 
clear 
exit 

case  XYZ  =  "N" 
clear 

set  talk  on 
set  status  on 

exit 

otherwise 

@  10,5  say  "Invalid  entry,  press  a  key-1 

wait"  " 

@  5,0  clear 

endcase 


enddo 

if  XYZ  =  "N" 

exit 
endif 

enddo 

return 
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